This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Optimization of conditional access to globals: thread-unsafe?

Andi Kleen <> writes:

> Ian Lance Taylor <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]