Jakub Jelinek <[EMAIL PROTECTED]> 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