On 11/18/2014 05:56 AM, Renlin Li wrote:
> Hi all,
>
> This patch should fix PR63762.
>
> Hard_reg allocated during IRA pass conflicts with hard_reg allocated
> in LRA pass because of inconsistent information between allocno and
> reg_pref.
>
> The staled reg_class information in reg_pref is used by LRA while
> doing hard register assignment. LRA makes wrong decision
> to choose same hard_reg number for pseudo registers with overlapped
> liveness.
>
>
> For this particular case manifested on arm target:
>
> (insn 180 183 184 15 (set (mem:SF (post_inc:SI (reg/v/f:SI 223 [ in
> ])) [2 MEM[base: in_68, offset: 4294967292B]+0 S4 A32])
> (reg/v:SF 290 [orig:224 val ] [224])) unpreditable-str.c:33
> 618 {*movsf_vfp}
> (expr_list:REG_INC (reg/v/f:SI 223 [ in ])
> (nil)))
>
> IRA:
> r290(2 ,SF, GENERAL_REGS) -> r278(2, SF, GENERAL_REGS) -> r224 (16,
> SF, VFP_LO_REGS)
> reg_pref[290] is set following its original_reg's(r224) info which is
> VFP_LO_REGS.
>
> LRA:
> r302(SI, GENERAL_REGS) -> r223(SI, GENERAL_REGS)
>
> while selecting hard register for r302, register class is checked
> first, r290 is VFP_LO_REGS (from reg_pref[290]), r302 is GENERAL_REGS,
> so they will never conflict. Thus, hard register number 2 is chosen
> for r302 without problem.
>
>
>
> A testcase is added for all targets as I think it's a middle-end
> issue. And sorry for not being able to simplify it.
> arm-none-eabi has been test on the model, no new issues. bootstrapping
> and regression tested on x86, no new issues.
>
> Is it Okay to commit?
Yes. Thanks very much for working on it and fixing it.
