Re: New problems with gcc-2.8.0 based code - NOW FIXED!

[Paul Koning <pkoning at xedia dot com>]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

 Paul> GCC 2.7.2.1 had a bug that showed up in some backends, and
 Paul> EGCS exposed it with more backends, where asm statements
 Paul> that should have been treated as unmovable were actually
 Paul> moved.  (Spefically, those with no output arguments; the
 Paul> documentation quite rightly says that those are always
 Paul> treated as if they were marked "volatile" even when not so
 Paul> marked.)

 Richard> Actually, the documentation is quite unclear since the
 Richard> example of "volatile" is one where there are no outputs and
 Richard> hence the "volatile" was unneeded according to a literal
 Richard> reading of the section.

I'd say the documentation is quite clear; the words "An instruction
without output operands will not be deleted or moved significantly,
regardless" are not particularly ambiguous.  The only thing that's at
all strange is that the example directly above it has no outputs and
yet is tagged "volatile".  Of course, that would explain the presence
of the word "regardless".

 Richard> I think the clear intent of the manual was to say that an
 Richard> asm without *operands* (i.e., an "old style") asm would
 Richard> always be treated as volatile, but that for others, you had
 Richard> to specify "volatile" to have it be treated that way.

I disagree (see below).  More importantly, it's very clear that the
writers of Linux code interpreted the documentation the same as I did.

 Richard> That's what the code does and what makes the most sense.

 Richard> If we say that asms with only inputs are *always* volatile,
 Richard> we have no way to write one that isn't volatile since there
 Richard> is no "novolatile" keyword!

 Richard> So my inclination is to treat this as a documentation error
 Richard> and a Linux bug, though we may want 2.8 to treat it this to
 Richard> give the Linux folks time to change things.

Well, it's not just 2.8.  The problem is there already in 2.7.2.1 at
least for some code sequences and for some backends.  (I tripped over
it in some R4000 code with 2.7.2.1.)  What has happened since then is
that the optimizers keep getting better, so more and more code that
was written in conformance to the documentation is now broken in
subtle and hard-to-debug ways.

More to the point, I believe the documented behavior is the most
logical, for the following reason:

The asm statement, just like any other statement or any function,
performs some operation that produces some effect in the system.  That
effect may consist of explicit results, or side effects, or both.

If an asm has outputs, it may be that these explicit outputs are its
only effect on the system state, i.e., it has no side effects.  If so,
the optimizer has all the information it needs to do the right thing.
However, an asm with explicit outputs may also have side effects, in
which case the optimizer should not move it around.  "volatile" warns
the optimizer of this.

It seems to be a common guideline that one tries to avoid combining
side effects and explicit outputs, so defaulting explicit output asm
statements to "not volatile" is logical.

On the other hand, an asm that has no explicit output clearly must
have side effects, otherwise it wouldn't have been put there.  So for
such an asm, "volatile" is the right treatment.

You mentioned the issue of an asm with inputs only that should still
be treated as non-volatile.  I have a hard time conceiving of such a
beast.  Can you show a real world example?

Whether an asm has inputs or not doesn't enter into the above
analysis, which is why I believe it is right to base the treatment
only on whether there are output operands.