On Tue, Apr 10, 2012 at 3:14 PM, Richard Sandiford
<rdsandif...@googlemail.com> wrote:
> 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 
> and that stmt would do the interleaving too?

Well, whatever we'd like to add (part of the atomic stuff would fit here, too,
just not the operation part like increment).


>  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

Reply via email to