Richard Guenther <richard.guent...@gmail.com> 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.) Richard
