This is the mail archive of the
mailing list for the GCC project.
Re: asm volatile("":::"memory) uncertainty.
- From: Tom Udale <tom at ionoptix dot com>
- To: Jeff Law <law at redhat dot com>, Andrew Haley <aph at redhat dot com>, David Brown <david at westcontrol dot com>, gcc-help at gcc dot gnu dot org
- Date: Tue, 10 May 2016 12:12:42 -0400
- 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> <31059279-2172-30ae-66ee-82ee94e35c01 at redhat dot com>
Hi Jeff and Andrew,
On 5/10/2016 12:07 PM, Jeff Law wrote:
On 05/10/2016 10:05 AM, Andrew Haley wrote:
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.
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
Of course there is. I was about to posit that simply making a bunch of
pointers to autos might have the desired effect but indeed my previous
experience with gcc indicates it would not fall for this kind of trick.
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.
Well, this is good. It at least means that things will not change
willy-nilly based on optimization and that things are in fact set at the
all the best,