> asm volatile + memory clobber should be the last resort barrier, if you skip > this out of the compiler or change its semantics (pinned by the current > documentation) at will, it's not unlikely you break existing code in favour > or saving some poor instructions.
Problem is that there is no current semantics. As Richard pointed out, RTL CSE just happens (probably due to historical reasons) to stop at volatile asm but this is not documented anywhere and people are certainly not (and probably never were) recommended to rely on this behavior. And other GCC optimizations may not behave similar way. > For example, I had the case that a costly computation (division an a > hardware that cannot divide) was moved into a section enclosed in asms which > disabled / re-enabled interrupts. This totally wrecked interrupt respond > times on the machine. Looks like a good example of volatile asm not being an optimization barrier. > Notice that such a division had no side effects from the C side or from the > compiler's point of view, but execution time and interrupt respond times > cannot be ignored by any software that does system programming. I agree that there's probably a need for an construct that would prevent code motion. But I'm not sure whether current volatile asm is intended (not even capable) for this. -Y
