Re: [PATCH] Reenable CSE of non-volatile inline asm (PR rtl-optimization/63637)

[Segher Boessenkool <segher@kernel.crashing.org>]

On Tue, Jan 13, 2015 at 12:45:27PM -0700, Jeff Law wrote:
> On 01/13/15 09:38, Segher Boessenkool wrote:
> >On Tue, Jan 13, 2015 at 05:18:19PM +0100, Jakub Jelinek wrote:
> >>3) on request from Richard (which Segher on IRC argues against), "memory"
> >>    clobber also prevents CSE;
> >
> >As extend.texi used to say:
> >
> >"
> >If your assembler instructions access memory in an unpredictable
> >fashion, add @samp{memory} to the list of clobbered registers.  This
> >causes GCC to not keep memory values cached in registers across the
> >assembler instruction and not optimize stores or loads to that memory.
> >You also should add the @code{volatile} keyword if the memory
> >affected is not listed in the inputs or outputs of the @code{asm}, as
> >the @samp{memory} clobber does not count as a side-effect of the
> >@code{asm}.
> >"
> >
> >so a "memory" clobber in a non-volatile asm should not prevent CSE.
> My reading of that paragraph is somewhat different.

It seems so.

I read that as "GCC can delete a memory clobber if it wants to" (just
like it can delete any other clobber when it wants to).

The only difference between ASM_OPERANDS and any other RTL is that
recog is useless for ASM_OPERANDS, it cannot tell you if after you
modify the construct you are left with something valid; so the only
thing the compiler can change about an asm is to delete it whole.
So unlike most RTL, where the compiler is free to remove a clobber
if what is left is valid RTL, the only way to delete a clobber from
an asm is to delete the whole asm.

> The key here is the memory clobber affects optimization of instructions 
> around the asm while the volatile specifier affects the optimization of 
> the ASM itself.

Those are roughly the effects, yes.  Writing unspecified stuff to
unspecified memory is a pretty heavy hammer ;-)

> A memory clobber must inhibit CSE of memory references on either side of 
> the asm because the asm must be assumed to read or write memory in 
> unpredictable ways.

I don't see how that follows.  The asm itself can be CSEd; its clobber
then disappears in a puff of smoke.

> The volatile specifier tells the compiler that the asm itself must be 
> preserved, even if dataflow shows the outputs as not used.

Yes.


Segher