User account creation filtered due to spam.
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 <email@example.com>
* tree-gimple.c (is_gimple_condexpr): Do not allow
* tree-eh.c (tree_could_trap_p): Fix handling of floating
Still the prediction will be off with exceptions turned on.
I can't see any reason why
--- 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?
Date: Mon Mar 21 13:50:26 2011
New Revision: 171236
2011-03-21 Richard Guenther <firstname.lastname@example.org>
* gimple.c (is_gimple_condexpr): Use tree_could_throw_p.
predict confusion about
pred = a CMP b;