Working version of AArch64 Address Lowering that uses reg + immediate addresses

[Andrew Dinn]

I have just posted a PR for a version of AArch64 Address Lowering that
takes into account usage, allowing it to use SCALED_IMMEDIATE (also
UNSCALED_IMMEDIATE) addressing.

  https://github.com/graalvm/graal-core/pull/275

The patch is composed of a series of commits the first two of which pave
the way for the implementation.

The 2nd commit involves introducing a distinct lowering phase for
AArch64 AddressLoweringByUsePhase which is used instead of the usual
AddressLoweringPhase.

As a consequence the installation of the phase has been factored out
into three subclasses of HotSpotSuitesProvider:

  AArch64HotSpotSuitesProvider
  AMD64HotSpotSuitesProvider
  SPARCHotSpotSuitesProvider

Achieving that required renaming  DefaultSuitesProvider and several of
its subclasses that implement SuitesCreator to use Creator instead of
Provider. This avoids a name clash over use of
AMD64HotSpotSuitesProvider and is the reason for the first commit.


The rest of the commits implement AArchAddressLoweringByUse which is
used in place of AArchAddressLowering. It extends the interface
AddressLoweringByUse defined by AddressLoweringByUsePhase.

The code in AArch64AddressNode.generate does not attempt to compute a
sensible LIRKind for the AArch64AddressValue. Instead it simply follows
the path used by the previous code. This code was and still is broken in
that the address kind does not actually reflect the kind of the
addressed value.

Unfortunately, that caused a catastrophic and horribly opaque problem in
the AArch64 code generation. At one specific point the (load address)
code was relying on the address kind to identify the transfer size for
the associated address access. In the case of a narrow object store the
write barrier snippet ended up treating the address of the previous
value as a 64 bit word (which turns out to be the LIRKind of almost all
addresses and is always the LIRKind of a field access). That error was
unimportant when there was no offset to be scaled. However, as soon as I
started using scaled displacement addressing the code blew up because it
scaled the displacement wrongly. The last commit fixes this by relying
on the scaling stored in the address rather than the address LIRKind.

This error in computing LIRKind for addresses is, perhaps, a trap lying
in wait for the future and might profit from either an overhaul or a
redesign.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander