RFR: 8173472: AArch64: C1 comparisons with null only use 32-bit instructions

[Stuart Monteith]

We're testing with "-XX:+TiedCompilation -XX:TieredStopAtLevel=1" to
try and catch C1 errors. I switched from building a special client
build to this as it seemed more sustainable and supported.

I've been trawling through the code, and there is definite confusion.

For example:

hotspot/src/share/vm/c1/c1_LIRGenerator.cpp
1290:LIRGenerator::do_getClass(Intrinsic *x)
  // FIXME T_ADDRESS should actually be T_METADATA but it can't because the
  // meaning of these two is mixed up (see JDK-8026837).

See  https://bugs.openjdk.java.net/browse/JDK-8026837 "Currently
metadata klass pointers (Klass*) are of type T_ADDRESS which is wrong;
the type should be T_METADATA."

There are places where T_ADDRESS type arguments are used as an array
element pointer, and others where it is used as metadata
pointers/offsets. Why treating T_ADDRESS types as jints works, I've
yet to find out, but I'm working from the assumption that is is as
much through luck as design.

BR,
   Stuart


On 1 February 2017 at 09:32, Roland Westrelin <rwestrel at redhat.com> wrote:
>
> Hi David,
>
>> Well that's what I'm questioning. Maybe one of the compiler folk
>> (Roland?) can chime in. C1 was 32-bit only but there was a proprietary
>> 64-bit version. I don't know if OpenJDK ever supported a 64-bit C1. The
>> code would have to have been adapted for tiered compilation.
>
> Tiered runs 64-bit c1 so the code is well tested. Building a client only
> 64 bit VM is forbidden by the build scripts and is as far as I know
> considered unsupported but given how much testing it gets with tiered
> compilation, in practice, it's on par with 32 bit c1.
>
> Roland.