Re: mips64 target erroneously reorders "asm"

[Paul Koning <pkoning at xedia dot com>]

>>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:

 Jim> asm("foo"); Note that `asm("foo")' and `asm("foo" : ...)' are
 Jim> rather different things.  The first one is an old-style K&R C
 Jim> asm.  The second one in a GNU C extended asm.

I was actually using the latter; didn't make that clear...

 Jim> The optimizer can not do anything with old-style asms; they are
 Jim> always treated as volatile.

 Jim> GNU C extended asms were created to solve this problem.  An
 Jim> extended asm is not volatile unless you mark it as so.  If an
 Jim> extended asm is not marked as volatile, then all optimizations
 Jim> are allowed, including instruction scheduling, and hence
 Jim> arbitrary reordering of extended asms may occur.  If you don't
 Jim> want this, then use volatile.

After people pointed me to the relevant docs, that's what I did and it
fixes the problem.

However, there does remain a point that's documented one way but
appears to work another way.  The specific code I have is:

    asm volatile("cache 0x15, (%0)" : : "g" (addr));

The doc says: "An instruction without output operands will not be
deleted or moved significantly, regardless, unless it is unreachable."
My code has no output operands, yet it *does* need "volatile" to
work.  Interestingly enough, the example in the documentation
immediately preceding the sentence I quoted also shows an "asm" with
no outputs and it has "volatile" on it.

So clearly the documentation is inconsistent and possibly broken.  It
makes a great deal of sense to do what it said -- if an "asm" has no
explicit outputs, it follows that it has side effects (either that or
it did nothing, but who cares about that case...).  For operations
with side effects you generally don't want reordering, so the stated
rule is appropriate.  Conversely, an "asm" that DOES have outputs can
sensibly be assumed to have no side effects unless otherwise declared.

 Jim> See the gcc info documentation (in particular the stuff in the
 Jim> extend.texi file).

Thanks.  Now if only index->volatile was able to find this section,
things would be great...

	paul