Re: [RFC] Do not consider volatile asms as optimization barriers #1

[Eric Botcazou <ebotcazou at adacore dot com>]

> 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