Re: volatile access optimization (C++ / x86_64)

[<Paul_Koning at Dell dot com>]

> On Jan 5, 2015, at 1:47 PM, DJ Delorie <dj@redhat.com> wrote:
> 
> 
>> One question: do you have an example of a non-volatile-safe machine so
>> I can get a feel for the problems one might encounter?  At best I can
>> imagine a machine that optimizes "add 0, [mem]" to avoid the
>> read/write, but I'm not aware of such an ISA.
> 
> For example, the MSP430 backend uses a macro for movsi, addsipsi3,
> subpsi3, and a few others, which aren't volatile-safe.  Look for
> "general_operand" vs "msp_general_operandâ.

To try to generalize from that: it looks like the operating principle is that an insn that expands into multiple references to a given operand isnât volatile-safe, but one where there is only a single reference is safe?

That would translate (roughly, at least) into: a general_operand that fits in a machine word is safe, one that doesnât isnât safe.

It sure is unfortunate that this is not documented, especially since the default behavior is not to allow volatile.  (And that default, even though it hurts performance, makes sense â it is the safe choice for correctness.)

It sounds like all the back-end maintainers (at least those who have general_operand in their MD files) should plan to do this work, if it hasnât already been done.  It sounds pretty simple and mechanical, at least if the summary I came up with above is accurate, or if someone can produce a description that is.

	paul