This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/41514] redundant compare instruction of consecutive conditional branches



------- Comment #3 from carrot at google dot com  2009-10-01 07:37 -------
(In reply to comment #2)
> Where does it come from? (Remember: option -dAP, then look at .s file)
> 

The first several instructions and corresponding rtl patterns are:

        cmp     r0, #63    
        beq     .L3
        cmp     r0, #63    
        bhi     .L4

(jump_insn 8 3 35 src/./test5.c:3 (set (pc)
        (if_then_else (eq (reg/v:SI 0 r0 [orig:135 ch ] [135])
                (const_int 63 [0x3f]))
            (label_ref 18)
            (pc))) 201 {*cbranchsi4_insn} (expr_list:REG_BR_PROB (const_int
2900 [0xb54])
        (nil))
 -> 18)

(note 35 8 9 [bb 3] NOTE_INSN_BASIC_BLOCK)

(jump_insn 9 35 36 src/./test5.c:3 (set (pc)
        (if_then_else (gtu (reg/v:SI 0 r0 [orig:135 ch ] [135])
                (const_int 63 [0x3f]))
            (label_ref 14)
            (pc))) 201 {*cbranchsi4_insn} (expr_list:REG_BR_PROB (const_int
5000 [0x1388])
        (nil))
 -> 14)

In thumb's instruction patterns, compare and branch instructions can't be
expressed separately. So we can't easily remove the second compare instruction
in middle end.

I just noticed the second conditional branch (larger than 63) is totally
unnecessary if we compare the equality with 63, 45, 47, 99 one by one. This is
another missed optimization exposed by this test case.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41514


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]