[C11-atomic] [patch] gimple atomic statements

[Richard Guenther]

On Tue, Apr 10, 2012 at 3:14 PM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> Richard Guenther <richard.guenther@gmail.com> writes:
>> On Fri, Apr 6, 2012 at 10:13 AM, Richard Sandiford
>> <rdsandiford@googlemail.com> wrote:
>>> Richard Guenther <richard.guenther@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?

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

Richard.

>  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