https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105342
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> Yes it is greater than a function call as it has to be a barrier to even
> memory which does NOT escape the function.
>
> Yes inlining does change it from dealing with escaped memory to even local
> ones. I doubt it can be fixed though because you have to mark which memory
> was active in the function where it was inlined from and such.
The question is whether we allow an asm (""::: "memory") to clobber
arbitrary parts of the stack the asm somehow magically can associate with
an automatic variable (the compiler could have promoted to a register!).
Basically it currently prevents optimization of stack storage across the
asm the asm cannot rely on being stack storage and thus has to assume it's
in registers. The docs say
--
@item "memory"
The @code{"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 @code{asm}. Further,
the compiler does not assume that any values read from memory before an
@code{asm} remain unchanged after that @code{asm}; it reloads them as
needed.
Using the @code{"memory"} clobber effectively forms a read/write
memory barrier for the compiler.
Note that this clobber does not prevent the @emph{processor} from doing
speculative reads past the @code{asm} statement. To prevent that, you need
processor-specific fence instructions.
--
I think clarifying that it does not protect 'memory' that can be elided
by the compiler wouldn't make it behave different in practice.
