Here is a bug in google branch which couldn't be reproduced in trunk.
But I think the same problem could probably exist in trunk too, just
havn't been exposed. I havn't created a small testcase successfully so
just describe the bug here and ask for suggestions to fix it.
compiler error we met:
internal compiler error: Max. number of generated reload insns per
insn is achieved (90)
In 1.cc.210r.ira, we saw a paradoxical subreg below.
insn 5 4 7 2 (set (reg:TI 106 [ __comp ])
(subreg:TI (reg:DI 107 [ __comp ]) 0)) 518.cc:203 85
{*movti_internal_rex64}
(nil))
In IRA phase,
r106's allocno is TImode and it is allocated hardreg R13 in IRA.
r107's allocno is DImode because the paradoxical subreg is not
considered in IRA, and it is allocated hardreg R15.
movti_internal_rex64's insn template is:
(define_insn "*movti_internal_rex64"
[(set (match_operand:TI 0 "nonimmediate_operand" "=!r ,o ,x,x ,m")
(match_operand:TI 1 "general_operand" "riFo,re,C,xm,x"))]
"TARGET_64BIT && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
In insn template, movti_internal_rex64's operand1 is of TImode (It is
different with r107 allocno's mode in IRA). process_alt_operands in
lra_constraints finds in in_hard_reg_set_p(...) that hardreg R15 could
not be paired with other reg (R15 is the last x8664 GENERAL_REG) to
save the TImode data , so for the first alternative, r107 requires a
reload insn.
1.c.211r.reload:
alt=0,overall=6,losers=1,rld_nregs=2
alt=1,overall=9,losers=1 -- reject
alt=2,overall=13,losers=2 -- reject
alt=3,overall=13,losers=2 -- reject
alt=4,overall=9,losers=1 -- reject
Choosing alt 0 in insn 5: (0) =r (1) riFo {*movti_internal_rex64}
The reload insn 195 below generated before insn 5 has the same pattern
with insn 5, so LRA will insert another reload insn for insn195 again,
which produces an endless loop...
That is why we meet the error "Max. number of generated reload insns
per insn is achieved (90)".
(insn 195 4 5 2 (set (reg:TI 181)
(subreg:TI (reg:DI 107 [ __comp ]) 0)) 518.cc:203 85
{*movti_internal_rex64}
(nil))
So I think the cause of the problem is that IRA uses r107's mode
(DImode) instead of using the paradoxical subreg mode (TImode).
Questions:
1. Any insight where to fix it? What I can imagine is either to change
r107 allocno's mode to be TImode in IRA, or loosen the check in
process_alt_operands in LRA?
2. When I was trying to create a small testcase to reproduce the
problem, I can get one producing the same paradoxical subreg as above,
but it is hard to control IRA to allocate r107 above just to hardreg
R15 (Only in that case the error will happen). Any suggestion to
achieve it?
Thanks,
Wei Mi.
