On Tue, Feb 14, 2017 at 03:48:38PM +0100, Richard Biener wrote:
> 2017-02-14 Richard Biener <rguent...@suse.de>
>
> PR tree-optimization/79460
> * tree-scalar-evolution.c (final_value_replacement_loop): Also
> allow final value replacement of floating point expressions.
>
> * gcc.dg/tree-ssa/sccp-3.c: New testcase.
>
> Index: gcc/tree-scalar-evolution.c
> ===================================================================
> --- gcc/tree-scalar-evolution.c (revision 245417)
> +++ gcc/tree-scalar-evolution.c (working copy)
> @@ -3718,8 +3718,10 @@ final_value_replacement_loop (struct loo
> continue;
> }
>
> - if (!POINTER_TYPE_P (TREE_TYPE (def))
> - && !INTEGRAL_TYPE_P (TREE_TYPE (def)))
> + if (! (POINTER_TYPE_P (TREE_TYPE (def))
> + || INTEGRAL_TYPE_P (TREE_TYPE (def))
> + || (FLOAT_TYPE_P (TREE_TYPE (def))
> + && flag_unsafe_math_optimizations)))
I think Segher mentioned in the PR that this should be better
flag_associative_math. Also, FLOAT_TYPE_P stands not just for
SCALAR_FLOAT_TYPE_P, but for COMPLEX_TYPE and VECTOR_TYPE thereof as well.
Does SCEV handle complex and vector types well (it would be really nice
if it could of course, but then we should use ANY_INTEGRAL_TYPE_P as
well to also handle complex and vector integers)?
Jakub
