> non-local labels should block most optimizations by the fact they > are a receiver of control flow and thus should have an abnormal > edge coming into them. If that's not the case (no abnormal edge) > then that's the bug to fix.
It's (of course) more complicated, you need to look at HP's fix and testcase to see why we need a full optimization barrier. See also the prologue and epilogue of many architectures which also need a blockage when they are establishing or destroying the frame. > Otherwise I agree with Richard. Please sit down and _exactly_ define > what 'volatile' in an asm provides for guarantees compared to non-volatile > asms. Likewise do so for volatile UNSPECs. Too late, we apparently all agree about what volatile asms and future volatile UNSPECs mean. :-) The remaining point is UNSPEC_VOLATILE, but the discussion can be deferred until the next stage 1. > A volatile shouldn't be a cheap way out of properly enumerating all > uses, defs and clobbers of a stmt. If volatile is used to tell the > insn has additional uses/defs or clobbers to those explicitely given > the only reason that may be valid is because we cannot explicitely > enumerate those. But we should fix that instead (for example with > the special register idea or by adding a middle-end wide "special" > "blockage" that you can use/def/clobber). For the time being this special blockage is UNSPEC_VOLATILE for RTL. -- Eric Botcazou
