https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93934
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |uros at gcc dot gnu.org
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, it seems to require -march=x86-64 to produce the fcmov. It's RTL that
creates that so this might be an angle of attack for a fix.
We expand from
;; basic block 9, loop depth 0
;; pred: 8
if (b_12(D) != 0)
goto <bb 11>; [56.18%]
else
goto <bb 10>; [43.82%]
;; succ: 11
;; 10
;; basic block 10, loop depth 0
;; pred: 9
;; 2
;; succ: 11
;; basic block 11, loop depth 0
;; pred: 9
;; 10
# iftmp.0_6 = PHI <result_3(9), 7.0e+0(10)>
return iftmp.0_6;
and in split3 we seem to have jump threaded the exit in BB reorder
which should be fine but then we somehow if-converted the other check.
Disabling both CE1 and CE2 avoids that. CE1 does
IF-THEN-JOIN block found, pass 1, test 5, then 7, join 9
scanning new insn with uid = 69.
scanning new insn with uid = 70.
if-conversion succeeded through noce_try_cmove
Removing jump 25.
deleting insn with uid = 25.
deleting insn with uid = 8.
deleting block 7
Conversion succeeded on pass 1.
IF-THEN-JOIN block found, pass 1, test 6, then 8, join 9
IF-CASE-2 found, start 6, else 8
maybe the backend should not advertise conditional moves with DF/SFmode and x87
math ...
