Eric Botcazou <ebotca...@adacore.com> writes: >> I strongly disagree with this. Outputs and clobbers have significant >> meaning even on volatile asms, asm volatile doesn't mean all registers and >> all memory are supposed to be considered clobbered. For memory you have >> "memory" clobber for that, for registers it is users responsibility to >> describe exactly what changes, either in clobbers or in outputs. >> The difference between non-volatile and volatile asm is, as the >> documentation states: >> >> The `volatile' keyword indicates that the instruction has important >> side-effects. GCC will not delete a volatile `asm' if it is reachable. >> >> Volatile asm acts as an optimization barrier to some extent, but it really >> can't modify registers or memory that aren't described as modified in the >> asm pattern. The important side-effects are of some other kind than >> modifying registers or memory visible from the current function. >> Ditto for UNSPEC_VOLATILE. > > Well, the last sentence would essentially void the entire argument I > think. It's well established in the RTL middle-end that > UNSPEC_VOLATILE can do pretty much everything behind the back of the > compiler.
As always when jumping in the middle of thread, I might well be missing the point sorry, but this sounded a bit extreme if taken literally. An UNSPEC_VOLATILE doesn't in itself force the function to save all call-saved registers, so an UNSPEC_VOLATILE that modifies those registers behind the back of the compiler would lead to us generating wrong code. And I thought UNSPEC_VOLATILEs that also clobber visible memory in an unpredictable way had to have something like (clobber (mem:BLK (scratch))). I thought Jakub's "the important side-effects are of some other kind than modifying registers or memory visible from the current function" applied to UNSPEC_VOLATILE too. Richard