Richard Guenther <richard.guent...@gmail.com> writes: > 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?
None. :-) But... >> Which is a roundabout way of wondering what the main difficulties >> would be in attaching things like directionality to a call. > > Directionality? [See above.] ...I was asking in the context quoted above, which seemed to be the bit that convinced you GIMPLE_ATOMIC would be OK after all. And the two main reasons in the bit quoted above seemed to be that GIMPLE_ATOMIC was more like GIMPLE_ASSIGN (which is true of the current internal fns too, and was why I was interested) and that we wanted to add the directionality of the memory model (which seemed at face value like something that could be attached 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 > 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. Ah, OK, so there'd still be a single gimple stmt (GIMPLE_LOAD or GIMPLE_STORE), and that stmt would do the interleaving too? Sounds good. I was worried at first that we'd have two separate stmts (e.g. a load and an interleave) which was what the internal fns were supposed to avoid. Thanks, Richard
