[aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot
akozlov at azul.com
Wed Aug 19 09:42:39 UTC 2020
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, ... 
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
> 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
>> 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).
More information about the aarch64-port-dev