Thanks for your guidance!
I see that ira-color.c::check_hard_reg_p take endianess into account
already. A difficulty is the param of ira-color.c::assign_hard_reg
only contains candidate allocno, so we need to put the correct mode in
ira_allocno in a early stage, for example, in
ira-build.c::create_insn_allocnos, then it is not a local fix in
ira-color.c::assign_hard_reg and may have wide impact on IRA. I am not
sure what other side-effect it will cause.
I can try that and see what will happen, and submit a candidate fix
for you to review.
Regards,
Wei Mi.
On Mon, Sep 23, 2013 at 2:04 PM, Vladimir Makarov <vmaka...@redhat.com> wrote:
> 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.
>
