On Fri, Apr 6, 2012 at 10:13 AM, Richard Sandiford <rdsandif...@googlemail.com> wrote: > 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. Directionality? > 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 least). Whatever 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 loads/stores that are in the MEM_REF /COMPONENT_REF / ARRAY_REF trees into proper "gimple" level information, like having an array of index, stride tuples for (multidimensional) 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. Richard.
