Optimization of conditional access to globals: thread-unsafe?

[Ian Lance Taylor]

Andi Kleen <andi@firstfloor.org> writes:

> 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.

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
involved.

My second patch looks through dominated blocks and stops at a memory
barrier.  So pretty much what you suggest.

Ian