[Bug target/53090] suboptimal ivopt

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53090

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> Sth like
> 
> Index: gcc/c-family/c-common.c
> ===================================================================
> --- gcc/c-family/c-common.c     (revision 209018)
> +++ gcc/c-family/c-common.c     (working copy)
> @@ -4415,19 +4415,21 @@ pointer_int_sum (location_t loc, enum tr
>  
>    /* Convert the integer argument to a type the same size as sizetype
>       so the multiply won't overflow spuriously.  */
> +  enum tree_code code = MULT_EXPR;
>    if (TYPE_PRECISION (TREE_TYPE (intop)) != TYPE_PRECISION (sizetype)
>        || TYPE_UNSIGNED (TREE_TYPE (intop)) != TYPE_UNSIGNED (sizetype))
> -    intop = convert (c_common_type_for_size (TYPE_PRECISION (sizetype),
> -                                            TYPE_UNSIGNED (sizetype)),
> intop);
> +    code = WIDEN_MULT_EXPR;
>  
>    /* Replace the integer argument with a suitable product by the object
> size.
>       Do this multiplication as signed, then convert to the appropriate type
>       for the pointer operation and disregard an overflow that occurred only
>       because of the sign-extension change in the latter conversion.  */
>    {
> -    tree t = build_binary_op (loc,
> -                             MULT_EXPR, intop,
> -                             convert (TREE_TYPE (intop), size_exp), 1);
> +    tree t = fold_build2_loc (loc, code,
> +                             c_common_type_for_size (TYPE_PRECISION
> (sizetype),
> +                                                     TYPE_UNSIGNED
> (sizetype)),
> +                             intop,
> +                             convert (TREE_TYPE (intop), size_exp));
>      intop = convert (sizetype, t);
>      if (TREE_OVERFLOW_P (intop) && !TREE_OVERFLOW (t))
>        intop = build_int_cst_wide (TREE_TYPE (intop), TREE_INT_CST_LOW
> (intop),
> 
> 
> but then you notice that for example SCEV doesn't handle WIDEN_MULT_EXPR.

But for example SCEV could be teached to _create_ the WIDEN_MULT_EXPRs
in the first place ... thus analyze for example _14 instead of as

(set_scalar_evolution
  instantiated_below = 4
  (scalar = _14)
  (scalar_evolution = {perm_9(D) + (sizetype) ((long unsigned int) j_5 * 4), +,
18446744073709551612}_1))

as

(set_scalar_evolution
  instantiated_below = 4
  (scalar = _14)
  (scalar_evolution = {perm_9(D) + (sizetype) (j_5 w* 4), +,
18446744073709551612}_1))