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

[Eric Botcazou <ebotcazou at adacore dot com>]

> Thanks for doing this.  FWIW I agree it's probably the best stop-gap fix.
> But the implication seems to be that unspec_volatile and volatile asms
> are volatile in different ways.  IMO they're volatile in the same way
> and the problems for volatile asms apply to unspec_volatile too.

I disagree, we need a simple way for the RTL middle-end as well as the back-
ends to block most optimizations across a specific point (e.g. a non-local 
label as in HP's fix) and UNSPEC_VOLATILE is the best candidate, at least in 
the short term.

> E.g. although cse.c will flush the table for unspec_volatile,
> it isn't the case that unspec_volatile forces a containing function
> to save all call-saved registers.  That would be excessive for a plain
> blockage instruction.  So again we seem to be assuming one thing in places
> like cse.c and another in the register allocator.  Code that uses the DF
> framework will also assume that registers are not implicitly clobbered
> by an unspec_volatile:
> [...]
> Also, ira-lives.c (which tracks the liveness of both pseudo and hard
> registers) doesn't mention "volatile" at all.

Yes, the definition of a blockage instruction is somewhat vague and I agree 
that it shoudn't cause registers to be spilled.  But it needs to block most, 
if not all, optimizations.

> So most passes assume that no pseudos or hard registers will be
> implicitly clobbered by unspec_volatile, just like for a volatile asm.
> And IMO that's right.  I think the rule should be the same for volatile
> asms and unspec_volatiles, and the same for registers as it already is for
> memory: if the instruction clobbers something, it should say so explicitly.

IMO that would buy us nothing and, on the contrary, would add complexity where 
there currently isn't.  We really need a simple blockage instruction.

> Volatile itself should:
> 
> (a) prevent deletion or duplication of the operation
> (b) prevent reordering wrt other volatiles
> (c) prevent the operation from being considered equivalent to any other
>     operation (even if it's structurally identical and has the same inputs)
> 
> but nothing beyond that.

Maybe UNSPEC_VOLATILE is a misnomer then and we should allow volatile UNSPECs 
along the above lines.

-- 
Eric Botcazou