From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Koning To: kenner@vlsi1.ultra.nyu.edu Cc: gcc2@cygnus.com, egcs@cygnus.com, torvalds@transmeta.com Subject: Re: New problems with gcc-2.8.0 based code - NOW FIXED! Date: Tue, 30 Dec 1997 13:52:00 -0000 Message-id: <9712302006.AA15131@kona.> References: <9712301949.AA01218@vlsi1.ultra.nyu.edu> X-SW-Source: 1997-12/msg01254.html >>>>> "Richard" == Richard Kenner 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.