Re: [tree-ssa] RFC: Never gimplify ASM_EXPRs

[Richard Henderson <rth at redhat dot com>]

On Thu, Jun 05, 2003 at 10:37:39PM -0700, Linus Torvalds wrote:
> ... if a lvalue rule makes the compiler more robust and
> makes the rules clearer, I'm all for it.

Ok, I think we should do this then.  I'll arrange for 3.3.1 to
generate a warning in the case we intend to deprecate.

One of the things I'm hoping to get out of this gimplification of
ASM_EXPR is a complete and accurate specification of semantics.
At the moment there's some code, and it does some stuff, and that's
about all you can know without spending a few years black-boxing it.

> NOTE! One reason I'm actually all for this is that I've always been
> worried about this issue for inline asms anyway. Take a look at the kernel
> <asm/bitops.h> header and the "ADDR" define - right now it's using a
> volatile, but historically it has had other "tricks" to make sure that the
> compiler doesn't do anything strange. It used to use a cast to an array
> instead of using a volatile pointer, just to make sure that gcc internally
> saw the thing as a MEM and didn't reload it or use some cached value
> thing.

The struct thing I always placed in a different class of workaround.
You had a read from a "large" object in memory.  At least for some
version of the compiler, this may have been interpreted as a read 
from ALL memory, resulting in a memory write barrier that didn't
affect cached reads.  I.e. possibly a bit better optimization-wise
than the normal "memory" clobber.

I have no particularly good ideas for a decent way to express that
properly.



r~