Memory ordering in C2

[David Holmes]

On 27/02/2014 8:13 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> We have a load that does the Acquire itself.  So that we don't get a
> useless  lwsync instruction after the load, the  match rule for
> MemBarAcquire is empty, i.e., does not emit an instruction.

I'm not a compiler person so grant me some slack here :) but it sounds 
to me like you want to be able to express the requirements as distinct 
nodes eg:

load -> membarAcquire -> <other op>

and then fold the membar back into the load if the platform has a 
loadWithAcquire capability.

David
-----

> Best regards,
>    Goetz.
>
>
>
> -----Original Message-----
> From: Andrew Haley [mailto:aph at redhat.com]
> Sent: Wednesday, February 26, 2014 10:52 AM
> To: David Holmes; Lindenmaier, Goetz; hotspot-dev Source Developers
> Subject: Re: Memory ordering in C2
>
> On 02/26/2014 04:32 AM, David Holmes wrote:
>> On 26/02/2014 1:41 AM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>>>   From what I've seen, C2 is enthusiastically emitting barrier nodes
>>>> around CompareAndSwap, so I'm not quite sure what this means.
>>> Yes, you are right ... that's again because we implement MemBArAcquire empty,
>>> but after the CompareAndSwap we need one, so we had to add it in the node ;)
>>> So same issue, distinguishing nodes would help!  The bad thing is that MemBarAcquire
>>> is implemented empty, that spoils the other uses.  If there is a way to avoid MemBarAcquire
>>> where it needs to be empty (after volatile load), then it can be implemented
>>> properly ...
>>
>> I'm unclear what you mean by "needs to be empty" ??
>
> "Does not need to be emitted," I think.
>
> Andrew.
>