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 12:52:37PM -0800, Richard Henderson wrote:
> > ./sysdeps/generic/malloc-machine.h:# define atomic_full_barrier() __asm ("" ::: "memory")
> 
> I think that it's uses like these -- which may well have been written
> by folks that also work on gcc -- that are proof that we have at least
> intended to support a memory clobber to be a full read+write barrier,
> and thus we must consider a memory clobber to be both a read and write.

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< ---

If "memory" would mean a read, the store to x[31] should not be considered
dead.  But it is, by all versions of GCC I have tried.

Because "memory" means a clobber of unspecified memory, all accesses *that
do happen* before it stay before it, and all accesses after it, after it.
It conflicts with all other memory accesses.  But it is a clobber, not an
output nor an input.

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.

> (The fact that all of these are automatically volatile and would never be CSEd
> is beside the point.  If the semantics of a memory clobber differ based on the
> volatile flag on the asm, I think that would be too ill-defined to actually
> support.)

The semantics of the memory clobber do not change.  The semantics of the
asm as a whole do though: any volatile has to be executed on the real machine
as on the abstract machine.


You could argue (and it seems you do) that we should change the current
semantics of the "memory" clobber to do imply reading any memory; I argue
that that would be a bad idea, see the first example code.


Segher