[Bug middle-end/33187] New: Missed cmove opportunity

["ubizjak at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

This testcase:

--cut-here--
double sgn (double __x) {
  return __x >= 0.0 ? 1.0 : -1.0;
}
--cut here--

shold compile using -m32 -O2 -march=i686 flags into the code using cmove
instruction, but it doesn't due to interference with float-extension of SFmode
constant into DFmode. Gcc figures out that 1.0 can be loaded as SFmode
constant, float-extended to DFmode. The RTL sequence in each arm then looks
like:

--cut here--
(insn 17 16 18 4 cmov.c:2 (set (reg:SF 64)
        (mem/u/c/i:SF (symbol_ref/u:SI ("*.LC2") [flags 0x2]) [3 S4 A32])) 90
{*
movsf_1} (expr_list:REG_EQUAL (const_double:SF 1.0e+0 [0x0.8p+1])
        (nil)))

(insn 18 17 19 4 cmov.c:2 (set (reg:DF 58 [ D.1658 ])
        (float_extend:DF (reg:SF 64))) 127 {*extendsfdf2_i387}
(expr_list:REG_DE
AD (reg:SF 64)
        (expr_list:REG_EQUAL (const_double:DF 1.0e+0 [0x0.8p+1])
            (nil))))
--cut here--

This effectivelly blocks ifcvt from generating conditional move in this case.

cmov instruction is generated if 1.0 and -1.0 constants are changed to (i.e.)
1.1 and -1.1, in order to disable automatic float-extend functionality:

sgn:
        fldl    .LC1
        fldz
        fldl    4(%esp)
        fucomip %st(1), %st
        fstp    %st(0)
        fldl    .LC2
        fcmovb  %st(1), %st
        fstp    %st(1)
        ret

This is a middle-end bug, as the problem with float-extend should be solved in
ifcvt.c


-- 
           Summary: Missed cmove opportunity
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ubizjak at gmail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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