Local variables reordering and 'asm volatile("" ::: "memory");'

[David Brown]

On 08/09/2019 16:46, Andrew Haley wrote:
> On 9/8/19 1:03 PM, Ayrat Gaskarov wrote:
> 
>>  From gcc docs: 'The "memory" clobber tells the compiler that the assembly
>> code performs memory reads or writes to items other than those listed in
>> the input and output operands (for example, accessing the memory pointed to
>> by one of the input parameters). To ensure memory contains correct values,
>> GCC may need to flush specific register values to memory before executing
>> the asm. Further, the compiler does not assume that any values read from
>> memory before an asm remain unchanged after that asm; it reloads them as
>> needed. Using the "memory" clobber effectively forms a read/write memory
>> barrier for the compiler.'
>> Does this mean that all data could be accessed including global variables,
>> data in heap and local variables? Or is it not true for local variables?
> 
> Yes, but only if the local variable has had its address taken. If it has not,
> then it is not reachable.

Having its address taken is not enough (AFAIK) - the address must be 
used in a way that forces the data into memory.  You can do useful 
things with an address of a local variable without the variable being 
put in memory:

#include <string.h>

unsigned int raw_float(const float f) {
     unsigned int x;
     memcpy(&x, &f, sizeof (x));
     return x;
}

Generated x86 code (gcc -O2):

raw_float(float):
         movd    eax, xmm0
         ret

Taking the address is not enough to make the local part of memory.


> 
>> For example:
>> int local = 5;
>> asm volatile("" ::: "memory");
>> local += 6;
>> Could it be reordered in the following way (because 'local' is local
>> variable and could not be accessed):
>> int local = 5;
>> local += 6;
>> asm volatile("" ::: "memory");
> 
> Yes.
> 
>> Could 'local' be optimized out in this case?
> 
> Yes.
>