Re: [PATCH] Add atomic type qualifier

[Andrew MacLeod <amacleod at redhat dot com>]

On 07/29/2013 12:06 PM, Joseph S. Myers wrote:
> On Mon, 29 Jul 2013, Andrew MacLeod wrote:
>
> > Blick. What were they smoking the night before... I guess we'll probably need
> > to enhance the current atomic patterns in RTL...    We should be able to
> > figure out that its floating point and invoke the appropriate RTL pattern
> > during expansion rather than an existing one.    OR just frigging call
> > libatomic and let it deal with it. :-)  I guess there wouldnt be any other
> > fallback available. Actually, thats a mess... no way for the librtary to know
> > its floating point unless you tell it somehow with new entry points or
> > somesuch..  very lame.
> Note that you only need *one* of the types to be floating-point for this
> issue to apply.  If you have
>
> _Atomic char c;
> float f;
>
> c /= f;
>
> then all the same requirements apply; there may be exceptions to discard
> not just from the division, but from the conversion of a float division
> result to char.
yes, unfortunately.   but  gimplification should turn this to:
t0 = c
t1 =(float) t0
t2 = t0 / f
t3 = (char) t2
c = t3

so we simply see a floating point division bracketted by load and store 
from a TYPE_ATOMIC expression. so we'd should be able to recognize the 
need for the floating point extra stuff based on the type of the 
operation .  and just wrap the whole blasted thing.

I must say, I'm not a fan :-)

> > I planned to do the work in gimplification... let the atomic decls through,
> > and during gimplification, loads or stores of an atomic decl would be
> > converted to the appropriate load or store builtin, and at the same time
> > recognize the  'decl = decl op value' expression and replace those as
> > appropriate with atomic_op_fetch operations.   I had discussed this at some
> > length with Lawrence crowl and Jeffrey Yasskin some time ago..   At
> > gimplification time we no longer know whether the original form was
> > decl op= val  or decl = decl op val;, but the decision was that it is ok to
> > recognize decl = decl op val and make that atomic.. it would still satisfy the
> > language requirements..
> I think that's probably OK (though, is this a theorem of the formal
> modelling work that has been done on the memory model?), but note it's not
I have no idea if its a theorem or not.
> just a decl but an arbitrary pointer dereference (the address of the
> lvalue is only evaluated once, no matter how many compare-and-exchange
> operations are needed), and the operation may end up looking like
>
> *ptr = (convert to type of *ptr) ((promote) *ptr op (promote) val)
>
> rather than a simple decl = decl op val.  Or something more complicated if
I think gimplification takes care of that as well since all assignments 
have to be in the form   DECL = VALUE op VALUE.. it constructs the 
sequence so that something like
*op_expr += 1

is properly transformed to
t0 = op_expr
  t1 = *t0
t2 = t1 + 1
*t0 = t2

With the TYPE_ATOMIC attribute set and rippled through the op_expr 
expression, we know that
*t0 is atomic in nature, so t1 is an atomic load, *t0 is an atomic 
store, and looking back at t2 = t1 + 1 can see that this is an atomic += 1.

same thing with a normal load of an expression... the TYPE_ATOMIC gimple 
attribute *ought* to tell us everything we need.

> the operation involves complex numbers - look at what gets for mixed real
> / complex arithmetic, for example.  Given
>
> _Atomic _Complex float f;
> double d;
>
> f += d;
>
> the atomicity is for the whole complex number (and so the
> compare-and-exchange needs to work on the whole number) although only the
> real part is modified by the addition.


complex I hadn't thought about until just now, I'll have to look.  I 
know we can deal with parts on complex sometimes.   Hopefully at 
gimplification time we still have the whole complex reference and if we 
just take care of that with the atomic builtins, we'll maintain the 
entire thing as we need.

Andrew



>