Re: [RFC/PATCH] doc: volatile considered evil

David Rientjes
2007-05-08T22:00:41Z

On Tue, 8 May 2007, Jeremy Fitzhardinge wrote:

> > In an asm construct, if all your input operands are modified and
> > specified as output operands as well, volatile must be added so
> > that the entire construct is not optimized away. Additionally,
> > it must be added if your construct modifies memory that is neither
> > listed in inputs nor outputs to the construct so that it is known
> > to have at least one side-effect.
>
> Hm. Is "asm volatile" necessary if you have a "memory" clobber? Would
> probably be the safest thing, I guess.
>

No, because the first requirement for 'volatile' in my paragraph above is
restricted to clobbering specific hard registers and an operand cannot
describe a hard register for a member when that register appears in the
clobber list. If an input operand is modified (i.e. not "accessed",
rather "modified" inclusive of the case where the previous value is the
same as the original value) then it must also be specified as an output
operand.

Now if all such output operands are to specify that the input operands
were "modified", 'volatile' is required to ensure the side-effects are
preserved or, otherwise, gcc is free optimize the entire asm construct
away since it appears to be unused.

> Yeah, they're completely different. They're not even analogous, really,
> which was my point. People confer more meaning to "asm volatile" than
> it actually has, because of the analogy with volatile variables/types.
> They would have been better off with something like "asm static", which
> isn't much more meaningful, but at least it doesn't mislead the reader
> into thinking it has anything to do with the other volatile.
>

You're point about reordering "asm volatile" constructs differs depending
on -mvolatile-asm-stop or -mno-volatile-asm-stop, however.

David