RFR(M): 8154826: AArch64: take better advantage of base + shifted offset addressing mode

Doerr, Martin martin.doerr at sap.com
Mon Apr 25 16:06:54 UTC 2016


Hi Roland,

seems like this issue is related to what I have sent out today:
RFR(S): 8154836: VM crash due to "Base pointers must match"
I also had to change the AddP case of final graph reshaping.

In one part of my change, I skip the graph transformation on non-X86 platforms when we're running in heap based compressed oops mode.

Maybe I have to remove that part of my change, or at least adapt it.
We should make sure that the changes don't get pushed on the same day.

Best regards,
Martin

-----Original Message-----
From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland Westrelin
Sent: Montag, 25. April 2016 15:51
To: hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR(M): 8154826: AArch64: take better advantage of base + shifted offset addressing mode



On 04/21/2016 10:23 AM, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8154826/webrev.00/
> 
> The aarch64 port implicitly transforms:
> (AddP base (AddP base address (LShiftL index con)) offset)
> into:
> (AddP base (AddP base offset) (LShiftL index con))
> in the ad file to embed the shift (and possibly and i2l conversion) into
> the addressing mode of a memory operation. Exposing that transformation
> in the ideal graph allows:
> 
> - (AddP base offset) to be scheduled (for instance outside a loop)
> - multiple identical (AddP base offset) to be commoned
> - (LShiftL index con) to be cloned during matching so that each memory
> access has its own

Further testing revealed some problems with the previous change so here
is a new webrev:

http://cr.openjdk.java.net/~roland/8154826/webrev.01/

Memory access instructions only accept a shift that matches the size of
the data being accessed (i.e. 2 for a 4 byte load). It's not always the
case that address expressions produced by c2 follow that constraint. As
expected, tt's very rare that it doesn't and seem to occur only with
unsafe. I added a predicate that skips the transformation of the address
subtree at the end of the optimization passes and prevent matching of
the address subtree if the constraint is not met for one use. As this is
uncommon, that seems good enough.

Roland.


More information about the hotspot-compiler-dev mailing list