Memory ordering in C2

[Andrew Haley]

This is related to the discussion about memory ordering raised by the PPC
team, but it's not the same.

Aarch64 has a weakly-ordered memory system, so needs memory barriers.
It also has load acquire and store release instructions, and I would
quite like to use these for volatile fields.  I have already made
sure that these instructions have the correct semantics.

However, I can't do that in the obvious way (by generating ld.acq and
st.rel and) defining empty versions of MemBarAcquire and MemBarRelease
in the ADfile because MemBarRelease isn't used only for volatile
fields.  It's also used for constructor barriers, and I need those.

A related problem is that C2 sprinkles these quite expensive barriers
in a number of other places, particularly around locks and atomic
operations.  This is painful because the atomic operations already
have a standard efficient sequence of instructions that has the
required semantics.

It seems to me that the back end needs to have far more control over
what barriers are emitted, and when.  I would like to be able to
control all of the explicit barriers in a machine-dependent way.  A
good start would be if I could disable barriers around locks without
affecting other places that really need them.  I don't want to have to
scribble #ifdef AARCH64 all over the machine-independent code.

I suppose the easiest way to do this would be to add a few new barrier
types.

Thoughts?

Thank you,
Andrew.