On Fri, Oct 24, 2014 at 10:01:52AM +0100, Jan Beulich wrote:
> > This changed because of my http://gcc.gnu.org/PR60663 fix.
> > In your testcase the inline asm doesn't have more than one output
> > (which IMNSHO is very much desirable not to CSE), and doesn't have explicit
> > clobbers either, but happens to have implicit clobbers (fprs and cc),
> > so CSE still could generate invalid code out of that without the fix
> > (if it decided to materialize the inline asm somewhere, instead of reusing
> > existing inline asm).
> > So, if we e.g. weakened the PR60663 fix so that it only bails out
> > if the inline asm contains more than one output. we'd need to fix up CSE, so
> > that it analyzes all the clobbers and doesn't consider asms as equivalent
> > just based on the ASM_OPERANDS, it needs to have the same clobbers too,
> > and either doesn't try to materialize it out without preexisting insn
> > if it has any clobbers.
>
> So why would clobbers in general matter? I can see memory clobbers
> to need special care, but any others? If two asm()-s only differ in the
Please start by looking at the PR the change fixed.
There CSE decided (ok, with the help of not very smart costs, but as the
testcase shows, it clearly can happen) to rematerialize the asm in a place
where the asm wasn't originally at all. At that point it just inserted the
single ASM_OPERANDS, without anything else, leaving the other ASM_OPERANDS
(the testcase had asm with two outputs) and in theory anything else (like
clobbers) out. Leaving the clobbers out completely is definitely not
desirable.
IMHO we should never CSE together asm with different clobbers, GCC
intentionally does not try to think what exactly the asm pattern does,
it is a black box, and if the programmer decides to use one set of clobbers
in one case and a different in another case, he might have a reason for
that.
Jakub
