This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Add atomic type qualifier
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, hp at bitrange dot com, Richard Henderson <rth at redhat dot com>
- Date: Mon, 29 Jul 2013 19:04:14 -0400
- Subject: Re: [PATCH] Add atomic type qualifier
- References: <51F2AEB1 dot 60408 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1307281928000 dot 28065 at digraph dot polyomino dot org dot uk> <51F6836F dot 6080400 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1307291553330 dot 12248 at digraph dot polyomino dot org dot uk>
On 07/29/2013 12:06 PM, Joseph S. Myers wrote:
On Mon, 29 Jul 2013, Andrew MacLeod wrote:
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
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
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
the operation involves complex numbers - look at what gets for mixed real
/ complex arithmetic, for example. Given
_Atomic _Complex float f;
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.
Ive been poking at this today, and Im wondering what you think of the
idea of adding a flag to MODIFY_EXPR,
and set that in the MODIFY_EXPR node when we create it from the "x op=
y" form in the front end. That flag seems to be free for expressions.
It will then be trivial to locate these expressions and issue a
builtin or the wrapper compare_exchange code during gimplification. We
just check if MODIFY_EXPR_IS_COMPOUND() is true and TYPE_ATOMIC() is set
on the expression type. (Ive already confirmed the atomic type is set
as the attribute ripples up to the MODIFY_EXPR node's type.) then we
know all the important bits from the MODIFY_EXPR to perform the operation.
Otherwise, it looks like it can get a bit hairy...
What do you think? As a side effect, we also only get it for the actual
statements we care about as well.