Re: Question regarding constraint usage within inline asm

[Michael Matz <matz@suse.de>]

Hi,

On Thu, 21 Feb 2019, Segher Boessenkool wrote:

> > That said, the "bug" in the case we're seeing, is that asmcons rewrote 
> > all of "input"'s pseudos, and it should be more careful to not create 
> > rtl with illegal constraint usage that LRA cannot fix up.  With the 
> > fix, operand %1 in the inline asm is no longer hard coded to r3 and it 
> > uses the pseudo instead, so everything is copacetic.
> 
> And that expand used one pseudo for everything in the asm is bad 
> already.

I'll contest that.  Asms aren't that special from an input-output 
perspective and shouldn't be (makes for clearer and hence more correct 
code).  hardregs are special, OTOH.  expand doesn't (and shouldn't) do 
anything special for

   _2 = _1 + _1;

(i.e. it should assign the same pseudo to both inputs), from which follows 
that it shouldn't do anything special for

  asm("" : "=r" (_2) : "r" (_1), "w" (_1))

either.  The picture changes if _1 corresponds to a local decl with an 
associated hard reg; those don't get SSA names for a reason.  But I 
believe you're worrying about the common case of off-the-mill SSA 
names.

Anything that would cause breakage by such behaviour of expand is to be 
rectified by LRA/reload, not by hackery within expand.

> If two inputs have identical constraints, sure, then it makes 
> sense perhaps (but does it really safe anything anyway?)  Otherwise it 
> does not.

The thing is that it doesn't make sense to do anything special for asms in 
this respect, and it actually goes against the natural flow of things to 
do anything special.  Think about how you would retain the necessary 
copies if we were to implement the restriction you want.  Say, given

  asm ("" :: "r" (_1), "w" (_1));

and you want to enforce that both inputs get different pseudo; so you 
start generating

  (set (p60) (p59))   // assume _1 sits in pseudo 59
  (set (p61) (p59))
  (asm (...) ("r" p60) ("w" p61))

How do you propose the (right now) obviously useless copies between two 
perfectly normal pseudos to be retained during the course of RTL 
optimization to not immediately end up with:

  (asm (...) ("r" p59) ("w" p59))

?  Sure, you could implement more of the hackery that looks at users of 
the copies and disable forwarding if they feed asms, but what for?  You 
can't remove LRA/reload code that deals with this situation anyway, so why 
not let it deal with it?  Another way to look at this is that LRA makes it 
so that those copies are implicitely always there but are only 
materialized if necessary because of conflicting constraints.

(Again the picture completely changes if one of the decls, and hence 
associated pseudo, has a hard-reg; and for that we do deal mostly 
correctly with it, except for the asmcons problem discussed here).


Ciao,
Michael.