RFR: 8361892: AArch64: Incorrect matching rule leading to improper oop instruction encoding [v2]

[Andrew Haley]

On Wed, 16 Jul 2025 09:29:49 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> That explains why ConP(BMB) is problematic. It is not -- as often stated -- because the value is not an address (offseting an address by a constant still gives an address). The problem is rather what value that address might have.

We-ell, hmm. I'm not sure I agree with that. On AArch64, addresses are either 48, 52, 0r 56 bits in length. Anything outside that is, literally, not an address. I guess one could call such things "unmappable addresses", but then we'd be arguing about definitions, which is usually sterile and pointless.

> > If C2 can be persuaded to treat the BMB as a value to be propagated like any other value then all of this conversation effectively becomes a don't care. Except for legacy architectures with insufficient registers, of course...
> 
> In principle that can already happen when the BMB is inserted into a C2 graph as a ConP -- although I have never seen it actually occurring. However, we have recently migrated barrier insertion to the back end for G1, Shenanadoah and ZGC, So, there is no opportunity for the compiler to perform constant elision in those three cases. 

That's fixable. We'd need the late barrier expansion to be passed the location of the card table base, hopefully in a register.

Surely we have to do _something_ sensible here. Adding a load latency to every oop store would be a Bad Thing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26249#issuecomment-3077937485