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

[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?

[Bug middle-end/47661] 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

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-21 13:50:35 UTC ---
Author: rguenth
Date: Mon Mar 21 13:50:26 2011
New Revision: 171236

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171236
Log:
2011-03-21  Richard Guenther  <rguenther@suse.de>

    PR middle-end/47661
    * gimple.c (is_gimple_condexpr): Use tree_could_throw_p.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/gimple.c

[Bug middle-end/47661] 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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.03.21 13:51:31
     Ever Confirmed|0                           |1

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-21 13:51:31 UTC ---
predict confusion about

 pred = a CMP b;
 if (pred)

remains.