Bug 47661 - predict is confused by FP comparisons when math can trap
Summary: predict is confused by FP comparisons when math can trap
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: missed-optimization
Depends on:
Blocks:
 
Reported: 2011-02-09 12:24 UTC by Richard Biener
Modified: 2011-03-21 13:51 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-03-21 13:51:31


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Biener 2011-02-09 12:24:02 UTC
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?
Comment 1 Richard Biener 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
Comment 2 Richard Biener 2011-03-21 13:51:31 UTC
predict confusion about

 pred = a CMP b;
 if (pred)

remains.