Re: PR63633: May middle-end come up width hard regs for insn expanders?

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, Oct 24, 2014 at 10:23:22AM -0600, Jeff Law wrote:
> On 10/24/14 08:03, Georg-Johann Lay wrote:
> >Investigating PR63633 turned out that the middle-end calls insn
> >expanders with hard registers, namely mulsi3 from avr back-end:
> >
> >(define_expand "mulsi3"
> >   [(parallel [(set (match_operand:SI 0 "register_operand" "")
> >                    (mult:SI (match_operand:SI 1 "register_operand" "")
> >                             (match_operand:SI 2 "nonmemory_operand" "")))
> >               (clobber (reg:HI 26))
> >               (clobber (reg:DI 18))])]
> >...
> >
> >is being called with operands[0] = (reg:SI 22).  This overlaps hard
> >(reg:DI 18) which extends from R18...R25.
> >
> >mulsi3 assumes all operands are pseudo registers and consequently the
> >generated insn raises an ICE in the remainder, and there are other cases
> >for other expanders where wrong code gets generated because the clobbers
> >clobber an hard-reg input operand.
> >
> >Is it in order to have hard registers as arguments to expanders (and
> >maybe also to insns) like that at expand time (pass .expand) ?
> >
> >It is easy enough to kick these hard regs into new pseudos in the
> >respective expanders, however the question arises where the culprit is:
> >
> >back-end or middle-end?
> >
> >Until PR63633 I've never seen middle-end coming up with hard regs that
> >way, thus bunch of avr insns have been written under that -- maybe wrong
> >-- assumption...
> I don't think you can assume you're always going to get a pseudo, though the
> vast majority of the time you will.  Normally it won't matter unless (as
> noted above) the expander/pattern has references (particularly
> sets/clobbers) of overlapping hard registers.
> 
> It's also probably worth investigating why you got the hard register in the
> first place as that may indicate something that's wrong or suboptimal either
> in the expanders or in the target dependent bits.

But I'd say, if you can't handle hard regs in the operands (either general,
or some specific ones), you should
force the hard regs into pseudos (all hard regs, or just the problematic
ones) in the expander.
So in this case, check if they overlap with those 2 regs, and force the
input operands into pseudos if they do; the output will be harder, guess
you'd need to emit the pattern into a pseudo and emit_move_insn it
afterwards to the hard reg.

	Jakub