This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C11-atomic] [patch] gimple atomic statements

Richard Guenther <> writes:
>> They can affect shared memory in some ways like a call, but don't have many
>> of the other attributes of call. ÂThey are really more like an assignment or
>> other operation with arbitrary shared memory side effects. ÂI do hope to be
>> able to teach the optimizers the directionality of the memory model
>> restrictions. Âie, ACQUIRE is only a barrier to hoisting shared memory
>> code... Âstores can be moved downward past this mode. RELEASE is only a
>> barrier to sinking code. Â RELAXED is no barrier at all to code motion. ÂIn
>> fact, a relaxed store is barely different than a real store... but there is
>> a slight difference so we can't make it a normal store :-P.
>> By teaching the other parts of the compiler about a GIMPLE_ ATOMIC, we could
>> hopefully lessen their impact eventually.
> Ok.  I suppose having a GIMPLE_ATOMIC is fine then.

Just for my own education really, but: does this mean that there'd
be unnecessary pessimisation in representing the thing as a call?
The interleaved load/store internal fns are really assignments too,
so if calls aren't right for that kind of operation, maybe we need
to replace the internal fns with something else.  Or at least come
up with some new call properties.

Which is a roundabout way of wondering what the main difficulties
would be in attaching things like directionality to a call.

Not arguing for anything here, just an onlooker wanting to understand. :-)

(BTW, it sounds like restricting memory accesses to GIMPLE_ASSIGN
might cause trouble for the interleave load/store stuff too.)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]