On 09/20/2013 07:31 PM, Wei Mi wrote:
> 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?
>
>
Sorry, I was away since Friday.
Yes, one place it can be fixed is in IRA. You should look at
ira-color.c::assign_hard_reg. Using the biggest mode of paradoxical
subregs of the pseudo can exclude assigning r15. The patch will be
not-trivial as it should take endianess into account.
I did not figure out yet should be it fixed in LRA too. Reload and LRA
were alwasy based that the global RA assigned the right hard-regs.
I can fix it by myself if you can wait for about 1 month. I am quite
busy with many things until end of stage1.
