[aarch64-port-dev ] RFR(S): 8087341: C2 doesn't optimize redundant memory operations with G1

[Andrew Dinn]

On 12/02/16 11:31, Andrew Haley wrote:
> On 12/02/16 11:25, Andrew Dinn wrote:
>> Not quite. Roland's change without the AArch64 patch triggered an assert
>> during CAS generation when the expected subgraph was not found.
> 
> Hmm.  Can this code not be changed to fail quietly, with no change
> to the code?  That's what optimizations generally do.

The assert is employed when generating AArch64 code for a CAS because
every CAS should *always* be capable of being optimized to use an
ldaxr/stlxr pair without the need for a top and tail dmb pair i.e. we
don't have a fall back. If we see a CompareAndSwap node in a subgraph
that does not have the expected shape then this can only mean that the
AArch64 code has gone out of sync with a change in the generic code. The
assert is used to find this mismatch during development/testing. By
placing as much as possible of this checking code in an ifdef ASSERT
region we avoid executing the check in production.

An assert is not employed when generating AArch64 code for a StoreX
because not all StoreX operations are volatile stores susceptible to
optimization. So, in this case if we don't find the relevant subgraph
then we just fall back to generating dmbs.

The predicates which control dmb generation apply to multiple rules --
those for StoreX, MemBarRelease and MemBarVolatile. The predicates are
all supposed to operate consistently so that when one predicate falls
back then they all do. However, that's only guaranteed by them knowing
exactly which shape to look for and correctly identifying it i.e. by me
having coded it correctly (but then that's true of a lot of code:-).

It would be nice to be able to cross-validate the actions of these rules
applied to some set of StoreN, MemBarRelease, MemBarVolatile and
CompareAndSwap nodes. However, I cannot see any way of correlating a
rule application to some given node with rule applications to related
nodes. Rule applications in a given sequence are not easily associated
with an originating volatile put/CAS (even when you know which ones they
are as happens during debugging they don't necessarily occur in a fixed
order).

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul
Argiry (US)