This is the mail archive of the
mailing list for the GCC project.
Re: PR63633: May middle-end come up width hard regs for insn expanders?
- From: Jeff Law <law at redhat dot com>
- To: Georg-Johann Lay <avr at gjlay dot de>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Fri, 24 Oct 2014 10:23:22 -0600
- Subject: Re: PR63633: May middle-end come up width hard regs for insn expanders?
- Authentication-results: sourceware.org; auth=none
- References: <544A5C14 dot 5030607 at gjlay dot de>
On 10/24/14 08:03, Georg-Johann Lay wrote:
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.
Investigating PR63633 turned out that the middle-end calls insn
expanders with hard registers, namely mulsi3 from avr back-end:
[(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 = (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
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.