From: Andrew MacLeod <amacleod@redhat.com>
To: Ian Lance Taylor <iant@google.com>
Cc: GCC <gcc@gcc.gnu.org>
Subject: Re: C++0x Memory model and gcc
Date: Thu, 06 May 2010 22:02:00 -0000 [thread overview]
Message-ID: <4BE33C55.8050205@redhat.com> (raw)
In-Reply-To: <mcrtyqkwyqo.fsf@dhcp-172-17-9-151.mtv.corp.google.com>
Ian Lance Taylor wrote:
> Andrew MacLeod <amacleod@redhat.com> writes:
>
>
>> I've been working for a while on understanding how the new memory
>> model and Atomics work, and what the impacts are on GCC.
>>
>
> Thanks for looking at this.
>
> One issue I didn't see clearly was how to actually implement this in
> the compiler. For example, speculated stores are fine for local stack
> variables, but not for global variables or heap memory. We can
> implement that in the compiler via a set of tests at each potential
> speculated store. Or we can implement it via a constraint expressed
> directly in the IR--perhaps some indicator that this specific store
> may not merge with conditionals. The latter approach is harder to
> design but I suspect will be more likely to be reliable over time.
> The former approach is straightforward to patch into the compiler but
> can easily degrade as people who don't understand the issues work on
> the code.
>
which is why the ability to regression test it is so important :-).
Right now its my intention to modify the optimizations based on the flag
settings. Some cases will be quite tricky. If we're CSE'ing something
in the absence of atomics, and it is shared memory, it is still possible
to move it if there is already a load from that location on all paths.
So the optimization itself will need to taught how to figure that out.
ie
if ()
a_1 = glob
else
if ()
b_2 = glob
else
c_3 = glob
we can still common glob and produce
tmp_4 = glob
if ()
a_1 = tmp_4
else
if ()
b_2 = tmp_4
else
c_3 = tmp4
all paths loaded glob before, so we can do this safely.
but if we had:
if ()
a_1 = glob
else
if ()
b_2 = notglob
else
c_3 = glob
then we can no longer do anything since we'd be introducing a new load
of 'glob' on the path that sets b_2 which wasn't performed before. If
there was another load of glob somewhere before the first 'if', then
commoning becomes possible again.
Some other cases won't be nearly so tricky, thankfully :-). I do think
we need to do it in the optimizations because of some of the complex
situations which can arise. We can at least try to do a good job and
then punt if it gets too hard.
Now, thankfully, on most architectures we care about, hardware detection
of data race loads isn't an issue. So most of the time its only the
stores that we need to be careful about introducing new ones. Im hoping
the actual impact to codegen is low most of the time
> I don't agree with your proposed command line options. They seem fine
> for internal use, but I think very very few users would know when or
> whether they should use -fno-data-race-stores. I think you should
>
I'm fine with alternatives. I'm focused mostly on the internals and I
want an individual flag for each of those things to cleanly separate
them out. How we expose it I'm ambivalent about as long as testing can
turn it them on and off individually.
There will be people using software data race detectors which may want
to be able to turn things on or off from the system default. I think
-fmemory-model= with options enabling at a minimum some form of 'off',
'system default', and 'on' would probably work for external exposure.
Andrew
next prev parent reply other threads:[~2010-05-06 22:02 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-06 15:43 Andrew MacLeod
2010-05-06 15:51 ` Richard Guenther
2010-05-06 16:11 ` Richard Guenther
2010-05-06 16:23 ` Andrew MacLeod
2010-05-07 9:15 ` Richard Guenther
2010-05-07 13:27 ` Andrew MacLeod
2010-05-07 14:26 ` Ian Lance Taylor
2010-05-06 15:54 ` Joseph S. Myers
2010-05-06 16:12 ` Andrew MacLeod
2010-05-06 20:40 ` Ian Lance Taylor
2010-05-06 22:02 ` Andrew MacLeod [this message]
2010-05-07 13:55 ` Mark Mitchell
2010-05-08 14:38 Jean-Marc Bourguet
2010-05-08 20:18 ` Albert Cohen
2010-05-10 4:40 ` Ian Lance Taylor
2010-05-10 17:23 ` Andrew MacLeod
2010-05-11 6:20 ` Miles Bader
2010-05-11 12:49 ` Andrew MacLeod
2010-05-12 5:21 ` Miles Bader
2010-05-12 13:10 ` Andrew MacLeod
2010-05-17 13:12 ` Michael Matz
2010-05-17 14:05 ` Ian Lance Taylor
2010-05-17 14:24 ` Michael Matz
2010-05-17 20:22 ` Ian Lance Taylor
2010-05-17 14:09 ` Andrew MacLeod
2010-05-17 14:55 ` Michael Matz
2010-05-17 16:36 ` Andrew MacLeod
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BE33C55.8050205@redhat.com \
--to=amacleod@redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=iant@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).