[PR63762]GCC generates UNPREDICTABLE STR with Rn = Rt for arm

Renlin Li renlin.li@arm.com
Tue Nov 18 11:31:00 GMT 2014


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?

gcc/ChangeLog:

2014-11-18  Renlin Li  <Renlin.Li@arm.com>

     PR middle-end/63762
     * ira.c (ira): Update preferred class.

gcc/testsuite/ChangeLog:

2014-11-18  Renlin Li  <Renlin.Li@arm.com>

     PR middle-end/63762
     * gcc.dg/pr63762.c: New.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-7.diff
Type: text/x-patch
Size: 3355 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20141118/ff84a86b/attachment.bin>


More information about the Gcc-patches mailing list