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

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

On Fri, Jan 23, 2015 at 10:48:50PM +0100, Jakub Jelinek wrote:
> On Fri, Jan 23, 2015 at 03:39:40PM -0600, Segher Boessenkool wrote:
> > I understand that argument.  But it is not what GCC actually does, nor
> > what I think it should do.  Consider this program:
> > 
> > --- 8< ---
> > int main(void)
> > {
> > 	int x[100], y[100];
> > 
> > 	x[31] = 42;
> > 
> > 	asm("# eww %0" : "=m"(y[4]) : : "memory");
> > 
> > 	return 0;
> > }
> > --- 8< ---
> 
> Here x isn't addressable, so it is certainly fine to DSE it.
> x shouldn't be considered memory.
> If the address of x escaped, either to the assembly or to some global var
> etc., then it probably shouldn't be removed.

But GCC does consider it memory.  If you look at the (tree) dump files
you see both arrays are clobbered after the asm.  Tree DCE removes the
store to x[31] nevertheless.

If the address of x escapes then of course the store to x[31] should
not be removed, irrespective of whether the clobber implies a read
or not.

> > Here is another program:
> > 
> > --- 8< ---
> > int main(void)
> > {
> > 	int x;
> > 
> > 	asm("# eww %0" : "=r"(x) : : "memory");
> > 	asm("# eww %0" : "=r"(x) : : "memory");
> > 
> > 	return x;
> > }
> > --- 8< ---
> > 
> > If "memory" would imply a write and a read, the identical asm here could
> > not be CSEd.  But it is.
> 
> Certainly not in GCC 4.9 nor trunk.  I've committed the patch because it
> makes GCC more aggressive again, just not for the "memory" case.

Yes, sorry, it is not actually removed by the CSE pass, but much much earlier
("deleted 2 trivially dead insns" in the early RTL "jump" pass).  My point
is that much of the compiler does not agree that "memory" implies a read.

But, to show RTL CSE removes the redundant insn here with older compilers:

--- 8< ---
int main(void)
{
	int x1, x2;

	asm("# eww %0" : "=r"(x1) : : "memory");
	asm("# eww %0" : "=r"(x2) : : "memory");

	return x1 + x2;
}
--- 8< ---

You can argue CSE should not do that.  But other passes feel free to
remove one of the asms (in the previous program), and they should not
either if "memory" implies a read and a write.

> In case of two idential non-volatile asms with "memory" clobber,
> if there are no intervening memory reads or writes, we can talk about
> allowing that to be CSEd despite "memory" being considered unspecified
> read and write.  If there are stores in between, we certainly should not CSE.

If there is a store inbetween, we cannot remove the later asm, which is
what CSE would do AFAIK.  But we can remove the *earlier* asm (and, in
fact, GCC does do that).


Segher