This is the mail archive of the
gcc-patches@gcc.gnu.org
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 13:36:02 -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> <51F69859 dot 3090907 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1307291641140 dot 12248 at digraph dot polyomino dot org dot uk>
On 07/29/2013 12:42 PM, Joseph S. Myers wrote:
On Mon, 29 Jul 2013, Andrew MacLeod wrote:
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.
You have things in a fairly complicated form, building up COMPLEX_EXPRs
out of operations on the individual parts of the complex operands.
I tried:
__complex__ double d;
int main (void)
{
d = 0;
d = d + 5;
}
and it seems to break it into:
d = __complex__ (0.0, 0.0);
and
d.1 = d;
d.0 = d.1;
D.1723 = REALPART_EXPR <d.0>;
D.1724 = D.1723 + 5.0e+0;
D.1725 = IMAGPART_EXPR <d.0>;
d.2 = COMPLEX_EXPR <D.1724, D.1725>;
d = d.2;
so again the loads and stores to (D) appear to be completely wrap the
entire complex operation, so this should be handle-able the same way...
So you really should be able to key into the atomic load from D followed
by the store to D and look at whats in between.
I thini is is straightforward in the gimplifier, we ought to have the d
=d op V expression at some point and be able to detect that d is the
same and atomic, and check op. but if it turns out not to be, then I
could simply turn those atomic loads and stores into atomic loads and
stores in the gimplifier and stop there., Then have a very early
always-run SSA pass pattern match looking for atomic stores fed from
atomic loads, and examine the operations in between, looking for
patterns that match d = d op v, and then turning the loads/store and
intermediate bits into the specified compare_exchange loops...
I'll get to this shortly.
Andrew