RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles

[Andrew Haley]

On 05/07/16 08:55, Andrew Dinn wrote:

> Hmm, logically I think you are correct that in terms of what the
> barrier nodes are /meant/ to represent there should be a
> MemBarVolatile in the sequence.

Yeah, exactly.  I am of the (rather quaint?) opinion that the IR
should be an accurate representation of what we want to happen.

> However, the code Alexei wrote was written to follow the existing
> pattern of usage which was established to avoid the double use of a
> locked instruction that would result on x86.

OK, right.

> Originally AArch64 handled the need to order stores /following/ the
> exchange store by naively translating the above to
> 
>   dmb (LoadStore|StoreStore)
>   ...
>   ldrx
>   ...
>   stlrx
>   ..
>   dmb (LoadLoad|LoadStore)

Right, I can do that, then.  That seems like a solution for now.

> So, we then added optimising rules which spot this pattern and improve
> the generated code. They inhibit the translation of the
> MembarRelease/Acquire and plant a ldarx stlrx pair
> 
> 
>   ...
>   ldarx
>   ...
>   stlrx
>   ..
> 
> which does all we need. If you are not seeing an stlrx then we have a
> problem. Is that the case?

Yes, because the rewrite rules don't know about the new CAS nodes
which I'm defining.  Besides that, the AArch64 back end is supposed to
work correctly even when using +UseBarriersForVolatile.

Andrew.