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

[Doug Simon]

Hi Andrew,

Sorry to have to ask you to do this, but as a result of the graal-core+truffle repo consolidation[1] can you please move your PR to https://github.com/graalvm/graal.

-Doug

[1] http://mail.openjdk.java.net/pipermail/graal-dev/2017-April/004960.html

> On 18 May 2017, at 11:53, Andrew Dinn <adinn at redhat.com> wrote:
> 
> 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