Re: -fno-tree-cselim not working?

[Ian Lance Taylor <iant at google dot com>]

Jakub Jelinek <jakub@redhat.com> writes:

> Unsafe optimizations in loop IM, if conversion, etc. really either need
> to be conditionalized on some new switch whether code should be thread
> safe or not, or just need to be disabled altogether.  Of course if
> gcc can prove the variable is written later on anyway before reaching any
> kind of barrier, it can do these optimizations anyway if it seems to be
> worthwhile.  MEMs in current function's stack frame can be considered safe
> as well.

If you can write down the rules, then I expect that people can figure
out how to implement them in the IR.  The rules could be something
like "never move a memory write out of a conditionally executed basic
block."  It would probably be helpful to look at the draft C++0x
memory model here--although that memory model would permit this
optimization, since the variable in question was not annotated.

The rules are going to have to be implemented as additional
dependencies.  If these dependencies are not in the IR, then the
various optimizers are going to go ahead and break them.

The reason explicit memory barriers, and explicit use of volatile,
avoid this problem is that they introduce additional dependencies.

I'm going to repeat that the optimization which started this all--the
use of a conditional add and an unconditional store--is not new.  This
is not some disaster that the compiler programmers have suddenly
sprung on you.  It's been there for years.

I'm also going to repeat that most people (other than kernel
programmers) are not going to want the new dependencies.  But that's
OK--if we can figure out how to implement it, we can make it an
option.

Ian