[aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot

[Anton Kozlov]

On 19.08.2020 11:45, Andrew Haley wrote:
> On 18/08/2020 16:21, Anton Kozlov wrote:
> 
>> Extra method overloads with for int, long, ... are added to catch
>> all (suitable) types used for intptr_t, int64_t. Now there are
>> overloads only for int (for literal values) and int64, latter
>> usually shares a fundamental type with intptr.  The new toolchain
>> provides different types for int64 and intptr.
> 
> Well, that's very silly. Out of interest, what is the fundamental
> type? Or are they compiler builtins?

I mean int, long, long long, ... [1]

intptr_t,int32_t,int64_t are  usually typedef's of int,long,...

Overloads operating on compiler (fundamental) types, not results of typedef.

> 
>> Then both overloads are not perfect for an intptr argument but
>> possible, so compilation is failed.  Providing additional overload
>> for intptr fixes compilation on new toolchain but breaks linux, as
>> intptr and int64 are different overloads for essentially the same
>> type.
> 
> I wonder what ISO C++ says about all of this. We are in danger of
> turning the code into an effectively unmaintainable mess because a
> Linux programmer makes a change, it breaks Darwin, and vice versa.
> 
> Are there any compiler flags that might help here?

I don't think there is a flag for that. Once we provided an overload for
(address) and e.g (int64_t), we need the rest set of overloads to capture (int)
for literals, (intptr) that may be a type unrelated to (int64_t)...

The process converges, I think. The provided overloads for mov() and Address()
are reasonable upper bound. The only possibility to break a build is to call
another function that provides some but not all overloads with an argument of a
new type. The user will have to choose to cast the argument or to introduce
overload. At the worst case, we would have a set of overloads for few widely 
used functions, following the pattern from this patch.

I think there is always a chance to break a build by changing shared code, and
cpu/aarch64 is becoming such.  Fortunately, build failures are easy to detect
and fix.

> 
>> Another approach is to leave a single overload for integer type, but
>> literal integer could still be ambiguously promoted to e.g. pointer
>> or int64. So every user will have to explicitly cast literal
>> integers to a certain type.
> 
> Maybe a template function for mov() ?
> 
> Be careful with sign extension. We want to make sure mov(reg, -1)
> works correctly.
> 

A template is interesting, it may save as a few lines and reduce the amount of
choices to several. I'll try to do that.

As for sign extension, that's why unsigned variants provided as well, so 
mov(r, -1) should choose mov(Register, int) and not mov(Register, unsigned int).

Thanks,
Anton

[1] https://en.cppreference.com/w/cpp/language/types