Re: PATCH: Fix 20000724-1.c

[Richard Henderson <rth at redhat dot com>]

On Mon, Apr 30, 2001 at 12:22:11PM -0700, Mark Mitchell wrote:
> In this test-case, if there was no overwriting of the memory, things
> would work OK.

No they wouldn't.  The stack frame got deallocated too early.
An interrupt could arrive and clobber the memory even if the
asm itself wouldn't.

This is exactly the original kernel test case that Jakub was
mentioning.

> So, that's why I was saying we could avoid the bug by not combining
> across a memory clobber.  I thought you said that was either too
> conservative, or not conservative enough -- but I'm not sure which,
> and I'm still not sure why.

I said it was irrelevant.

> ] If the side-effects of your instruction are not purely external, but
> ] will affect variables in your program in ways other than reading the
> ] inputs and clobbering the specified registers or memory, you should
> ] write the `volatile' keyword to prevent future versions of GNU CC
> ] from moving the instruction around within a core region.

On re-reading, this is incredibly misleading.

> In fact, that sentence seems to say that a volatile asm can mess
> with anything it wants without having anything in its clobbers at all!

Definitely incorrect.

> Can you clarify this point, and I can try to clean up the
> documentation?

A volatile asm (in a reachable basic block) will not be removed.

It will act as a scheduling barrier so that individual instructions
won't get moved across it.  Note that this is a scheduling barrier,
and not some sort of "optimization" barrier.  We will do CSE, 
combination, dead code elimination, and register allocation around
the asm.

The scheduling barrier feature is useful.  For instance,

	*(volatile int *)addr = foo;
	asm volatile ("eieio" : : );

Assume "addr" contains the address of a memory mapped device register.
The PowerPC eieio instruction (Enforce In-order Execution of I/O)
tells the cpu to make sure that the store to that device register
happens before it issues any other I/O.

---

Thinking about this, there is one bit of information that is missing
from the asm in the original test case -- it didn't mention that it
wanted to *read* the memory at the address it was given.  Changing the
original test case to 

  asm volatile("call ___checkme" : : "c" (x), "m"(*x));

does do the right thing.  However, this is an incomplete solution
since it's easy enough to fiddle things around to obscure the fact
that we're dealing with a stack address.

It looks as if Jan's regmove changes never got in.  Cause they
definitely should have handled this sort of case.  I thought I
remembered acking one version of them though...

I'll track them down and see what's up.


r~