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.
