> 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
