On Tue, 14 Feb 2017, Jakub Jelinek wrote:
> 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.
We don't associate anything though.
Technically we could, for constant niter, fully simulate
the rounding effects (flag_rounding_math would need checking then).
Given that reassoc transforms x + x + x + x -> 4 * x with just
-funsafe-math-optimizations using that flag is at least consistent.
I think flag_associative_math wasn't meant to change the number of
rounding steps. flag_fp_contract_mode controls this IMHO, but we
have the reassoc precedent...
> 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)?
SCEV should gate out types it doesn't handle itself -- it already
gates out VECTOR_TYPE:
static tree
analyze_scalar_evolution_1 (struct loop *loop, tree var, tree res)
{
tree type = TREE_TYPE (var);
gimple *def;
basic_block bb;
struct loop *def_loop;
if (loop == NULL || TREE_CODE (type) == VECTOR_TYPE)
return chrec_dont_know;
and given that it special-cases only REAL_CST, FIXED_CST and INTEGER_CST
in get_scalar_evolution I doubt it handles anything else reasonably.
But as I said, it's SCEVs job to reject them, not users of the API.
I see no reason to not allow vectors for example (it's just the
code might be not ready and uses wrong tree building interfaces).
Richard.
> Jakub
>
>
--
Richard Biener <rguent...@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB
21284 (AG Nuernberg)
