Memory ordering in C2 (original) (raw)
Andrew Haley aph at redhat.com
Wed Feb 26 01:52:19 PST 2014
- Previous message: Memory ordering in C2
- Next message: Memory ordering in C2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message: Memory ordering in C2
- Next message: Memory ordering in C2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]