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 rtl-optimization/40987] Wrong optimization with if-conversion



------- Comment #9 from mikpe at it dot uu dot se  2009-09-19 16:57 -------
Seems like an if-conversion bug, in particular noce_try_store_flag_constants()
appears to break on HWI32 platforms when long long literals are involved.

In this test case, noce_t_s_f_c() is invoked with an IF where a (the false
value) and b (the true value) are both DImode CONST_INTs. a is zero. b is
stored as 0x80000000, which is truncated but sign-extends to the correct value.

noce_t_s_f_c() then computes a subtraction and some log2() on these truncated
values, and selects the second code generation template "x = (test != 0) <<
3;".
The code becomes (from the ce1 dump file):

(insn 27 8 28 2 pr40987.c:4 (parallel [
            (set (reg:DI 62)
                (sign_extend:DI (reg/v:SI 60 [ arg ])))
            (clobber (reg:CC 17 flags))
            (clobber (scratch:SI))
        ]) 90 {*extendsidi2_1} (nil))

(insn 28 27 29 2 pr40987.c:4 (parallel [
            (set (reg/v:DI 58 [ val ])
                (lshiftrt:DI (reg:DI 62)
                    (const_int 63 [0x3f])))
            (clobber (reg:CC 17 flags))
        ]) 394 {*lshrdi3_1} (nil))

# since this is a logical downshift, it produces 0 or 1 from the sign bit

(insn 29 28 17 2 pr40987.c:4 (parallel [
            (set (reg/v:DI 58 [ val ])
                (ashift:DI (reg/v:DI 58 [ val ])
                    (const_int 31 [0x1f])))
            (clobber (reg:CC 17 flags))
        ]) 356 {*ashldi3_1} (nil))

# which is shifted up to produce 0 or 0x80000000, the high 32 bits are lost

All gcc-4.x releases have this bug. It does not trigger in gcc-3.4.6. There it
seems that the true/false values are swapped compared to 4.x, and a test near
the top of noce_t_s_f_c() causes it to bail out and not perform the conversion.
(The test looks the same in 4.x, but the IF-operands are swapped so it does not
bail.)

I don't know if this code can be fixed to handle longer-than-HWI literals. The
simplest solution might be to just detect the situation and bail out.


-- 


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


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