This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Optimization of conditional access to globals: thread-unsafe?
- From: Andi Kleen <andi at firstfloor dot org>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 27 Oct 2007 19:02:10 +0200
- Subject: Re: Optimization of conditional access to globals: thread-unsafe?
- References: <e2e108260710260541n61462585u99de9bc0617720f4@mail.gmail.com.suse.lists.egcs> <e2e108260710260620k2a2e21b3t1d6c052f14d36094@mail.gmail.com.suse.lists.egcs> <20071026143334.GA5041@moonlight.home.suse.lists.egcs> <m38x5pj3ig.fsf@localhost.localdomain.suse.lists.egcs> <20071026155101.GB5041@moonlight.home.suse.lists.egcs> <016201c817e9$5454edd0$2e08a8c0@CAM.ARTIMI.COM.suse.lists.egcs> <20071026161739.GC5041@moonlight.home.suse.lists.egcs> <Pine.LNX.4.64.0710261836440.23011@wotan.suse.de.suse.lists.egcs> <m33avxfu2i.fsf@localhost.localdomain.suse.lists.egcs>
Ian Lance Taylor <iant@google.com> writes:
>
> What do people think of this patch? This seems to fix the problem
> case without breaking Michael's case. It basically avoids store
> speculation: we don't write to a MEM unless the function
> unconditionally writes to the MEM anyhow.
I'm not sure "function" is a good area to check here. It might well be that
a function has parts where it is ok to change memory (because a lock is hold)
and another part where this is not true. But your check would
mix them both togeter.
Basic block (or rather super block without function calls or memory barriers)
would be better.
-Andi