On Fri, Apr 6, 2012 at 10:13 AM, Richard Sandiford
> 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?
No, there are not. They are more pessimized than GIMPLE_ASSIGNs
(unless you handle them specially in a few places). But the same is
true for GIMPLE_ATOMIC. The question is one of convenience as
far as I understand. In general I would like to avoid new GIMPLE codes,
especially "random" ones. You can do everything with builtins or
internal functions just fine.
> 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.
What missed optimizations do you see?
> 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.)
Well. In the end my plan was to have a GIMPLE_LOAD and GIMPLE_STORE
stmt, where the load would load to an SSA name and the store would store from
a constant or an SSA name. Advantages would be simplified data-flow analysis
and things like aggregate copy propagation and value-numbering for free. It
would also be easier to attach special data / properties to the now
single load / store
sites (where in calls you can have an arbitrary number of loads at
special property the interleaved load/store has would be stored there, too. The
idea was to be able to fold most of the implicit information about
are in the MEM_REF /COMPONENT_REF / ARRAY_REF trees into proper "gimple"
level information, like having an array of index, stride tuples for
array accesses. Think of it like a place where we can properly embed the
MEM_ATTRs we have on the RTL side for example. That's much easier if
there were loads/stores only in very defined places.