This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: asm volatile("":::"memory) uncertainty.
- From: Andrew Haley <aph at redhat dot com>
- To: 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 17:05:51 +0100
- 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>
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.
> It appears that the "memory" clobberer is operating at a level much
> lower than the C statement which means you _really_ need to be careful
> with it since what is memory and what is not could easily change with
> the addition or removal of reference (i.e. something that once was held
> in memory is not any longer because a removed reference made another
> variable be better suited to the stack allowing the one-time memory
> variable the better candidate for a register).
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.
Andrew.