This is the mail archive of the
mailing list for the GCC project.
Re: asm volatile("":::"memory) uncertainty.
- From: Jeff Law <law at redhat dot com>
- To: Andrew Haley <aph at redhat dot com>, Tom Udale <tom at ionoptix dot com>, David Brown <david at westcontrol dot com>, gcc-help at gcc dot gnu dot org
- Date: Tue, 10 May 2016 10:07:54 -0600
- Subject: Re: asm volatile("":::"memory) uncertainty.
- Authentication-results: sourceware.org; auth=none
- References: <f3141159-2f2a-6317-8dd6-da0aa64eca14 at ionoptix dot com> <5731A8BE dot 2090507 at redhat dot com> <5731D7B3 dot 1060007 at westcontrol dot com> <6482230d-d824-c20a-5984-9be81d20c9f2 at ionoptix dot com> <573206DF dot 8040307 at redhat dot com>
On 05/10/2016 10:05 AM, Andrew Haley wrote:
And note that there's a variety of analysis and transformations that
will try to eliminate the address-of so that the object is no longer
On 05/10/2016 04:58 PM, Tom Udale wrote:
To my mind, the only reason that these would not be considered "memory
references" is because the compiler has already decided to put the
memory into registers (true these are mostly automatic variables so they
can easily be put into registers). But from an abstract machine
standpoint a=b is a memory read and a memory write is it not (or is that
a totally incorrect statement)? It seems odd therefore that a register
allocation choice can fundamentally alter program behavior.
An auto variable is only considered to be "memory" if its address
is taken with & . "memory" means that this object is reachable from
some pointer somewhere.
Not really. If a variable is not addressable by any means then it
can't be affected by a memory access. Whether the compiler spills
that variable to a stack frame makes no difference.