PATCH: PR 16590

Jeffrey A Law law@redhat.com
Mon Aug 30 21:11:00 GMT 2004


On Sun, 2004-08-29 at 13:41, Mark Mitchell wrote:
> This PR is a case where GCSE creates an invalid REG_EQUAL note.  (More
> details are in the audit trail.)  I asked Jeff Law for his thoughts on
> this patch about ten days ago, but haven't heard back, so I'm going
> ahead and checking this in.
> 
> Tested on i686-pc-linux-gnu, applied on the 3.4 branch and on the
> mainline.
Sorry, I didn't expect the cross-town move to leave me without an
internet connection for so long.

I haven't followed all the changes to gcse which arrange for it
to create REG_EQUAL notes.  However, I do know most of those changes
were done in an attempt to improve later optimizations, so it's
possible your change is pessimizing code in some ways.

But more importantly, I don't see how that REG_EQUAL note is
incorrect.  There are two paths by which we can reach the supposed
bogus REG_EQUAL note.  Looking at the .gcse from GCC 3.4 we have:
  

(insn 49 45 113 0 (set (reg:SI 86)
        (mem/s:SI (plus:SI (reg/f:SI 20 frame)
                (const_int -24 [0xffffffe8])) [4 p.p+0 S4 A32])) 36
{*movsi_1} (nil)
    (nil))
                                                                                                         
(insn 113 49 50 0 (set (reg:SI 76 [ p.p ])
        (reg/v/f:SI 71 [ start ])) 36 {*movsi_1} (nil)
    (nil))
                                                                                                         
(insn 50 113 51 0 (set (reg:CCZ 17 flags)
        (compare:CCZ (reg/v/f:SI 71 [ start ])
            (reg/v/f:SI 71 [ start ]))) 2 {*cmpsi_1_insn} (nil)
    (nil))
                                                                                                         
(jump_insn 51 50 104 0 (set (pc)
        (if_then_else (ne (reg:CCZ 17 flags)
                (const_int 0 [0x0]))
            (label_ref 58)
            (pc))) 342 {*jcc_1} (nil)
    (nil))
                                                                                                         
(note 104 51 56 1 [bb 1] NOTE_INSN_BASIC_BLOCK)
                                                                                                         
(insn 56 104 114 1 (parallel [
            (set (reg/f:SI 77)
                (plus:SI (reg/f:SI 20 frame)
                    (const_int -11 [0xfffffff5])))
            (clobber (reg:CC 17 flags))
        ]) 138 {*addsi_1} (nil)
    (nil))
                                                                                                         
(insn 114 56 57 1 (set (reg:SI 86)
        (reg/f:SI 77)) -1 (nil)
    (nil))
                                                                                                         
(insn 57 114 58 1 (set (mem/s:SI (plus:SI (reg/f:SI 20 frame)
                (const_int -24 [0xffffffe8])) [4 p.p+0 S4 A32])
        (reg/f:SI 77)) 36 {*movsi_1} (nil)
    (nil))
                                                                                                         
(code_label 58 57 105 2 3 "" [1 uses])
                                                                                                         
(note 105 58 112 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
                                                                                                         
(insn 112 105 63 2 (set (reg:SI 78 [ p.p ])
        (reg:SI 86)) -1 (nil)
    (expr_list:REG_EQUAL (mem/s:SI (plus:SI (reg/f:SI 20 frame)
                (const_int -24 [0xffffffe8])) [4 p.p+0 S4 A32])
        (nil)))


Note carefully that in both paths which reach insn 112 that 
(reg:SI 86) contains the value in memory location 
(mem (plus (frame) (const_int -24))

So it seems to me you're papering over the real problem.

jeff




More information about the Gcc-patches mailing list