This is the mail archive of the
mailing list for the GCC project.
Re: Optimization of conditional access to globals: thread-unsafe?
- From: Ian Lance Taylor <iant at google dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: 27 Oct 2007 11:15:24 -0700
- Subject: Re: Optimization of conditional access to globals: thread-unsafe?
- References: <email@example.com> <firstname.lastname@example.org> <20071026143334.GA5041@moonlight.home.suse.lists.egcs> <email@example.com> <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.firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
Andi Kleen <email@example.com> writes:
> Ian Lance Taylor <firstname.lastname@example.org> 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.
The second version of my patch would not do that, because the lock
operation would be a memory barrier.
> Basic block (or rather super block without function calls or memory barriers)
> would be better.
Basic block would be useless, since there are already two basic blocks
My second patch looks through dominated blocks and stops at a memory
barrier. So pretty much what you suggest.