[Bug middle-end/47661] New: predict is confused by FP comparisons when math can trap

[rguenth at gcc dot gnu.org]

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

           Summary: predict is confused by FP comparisons when math can
                    trap
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: rguenth@gcc.gnu.org
                CC: hubicka@gcc.gnu.org, espindola@google.com


Without -fno-trapping-math we split away FP comparisons from the actual
conditional jump like

  D.2683 = x < 0.0;
  if (D.2683 != 0) goto <D.2684>; else goto <D.2685>;

this results in different prediction results for BB frequencies compared to

  if (x < 0.0) goto <D.2683>; else goto <D.2684>;

which is odd (for C-ray this causes us to belive ray_sphere is more
costly time-wise with -ffast-math).

It is dubious that we use tree_could_trap_p in is_gimple_condexpr
instead of tree_could_throw_p (which would conditionalize the above
on -fnon-call-exceptions -fexceptions at least).  4.3 did neither,
tuples introduced that check with

2008-05-02  Rafael Espíndola  <espindola@google.com>

        * tree-gimple.c (is_gimple_condexpr): Do not allow
        trapping comparisons.
        * tree-eh.c (tree_could_trap_p): Fix handling of floating
        point comparisons.

Still the prediction will be off with exceptions turned on.

I can't see any reason why

Index: gimple.c
===================================================================
--- gimple.c    (revision 169963)
+++ gimple.c    (working copy)
@@ -2581,7 +2581,7 @@ bool
 is_gimple_condexpr (tree t)
 {
   return (is_gimple_val (t) || (COMPARISON_CLASS_P (t)
-                               && !tree_could_trap_p (t)
+                               && !tree_could_throw_p (t)
                                && is_gimple_val (TREE_OPERAND (t, 0))
                                && is_gimple_val (TREE_OPERAND (t, 1))));
 }

would be incorrect.  Rafael, do you remember anything about the reasoning
to use tree_could_trap_p instead of tree_could_throw_p?