This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C11-atomic] [patch] gimple atomic statements


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?

> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]