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

[Georg-Johann Lay]

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...


Johann