Re: [PATCH] fold: Optimise fold_view_convert_expr

[Richard Biener <richard.guenther@gmail.com>]

On Sun, Dec 5, 2021 at 11:00 PM Richard Sandiford via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> When compiling an optabs.ii at -O2 with a release-checking build,
> there were 210,172 calls to fold_view_convert_expr.  99.8% of them
> were conversions of an INTEGER_CST to an ENUMERAL_TYPE, so this patch
> adds a fast(er) path for that case.
>
> Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?
>
> Richard
>
>
> gcc/
>         * fold-const.c (fold_view_convert_expr): Add a fast path for
>         conversions of INTEGER_CSTs to other integral types.
> ---
>  gcc/fold-const.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/gcc/fold-const.c b/gcc/fold-const.c
> index 0b9a42f764a..19613015ddb 100644
> --- a/gcc/fold-const.c
> +++ b/gcc/fold-const.c
> @@ -9128,6 +9128,13 @@ fold_view_convert_vector_encoding (tree type, tree expr)
>  static tree
>  fold_view_convert_expr (tree type, tree expr)
>  {
> +  /* Conversions of INTEGER_CSTs to ENUMERAL_TYPEs are very common,
> +     so handle them directly.  */
> +  if (INTEGRAL_TYPE_P (type)
> +      && TREE_CODE (expr) == INTEGER_CST
> +      && TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (expr)))
> +    return wide_int_to_tree (type, wi::to_wide (expr));

I suppose that TREE_CODE (expr) == INTEGER_CST &&
tree_nop_conversion_p (type, TREE_TYPE (expr))
might be more complete?  In fact, it might be possible to do

  if (TREE_CODE (expr) == INTEGER_CST)
    {
       gcc_checking_assert (tree_nop_conversion_p (type, TREE_TYPE (expr));
       return wide_int_to_tree (type, wi::to_wide (expr));
    }

or at least

  if (TREE_CODE (expr) == INTEGER_CST)
    {
       gcc_checking_assert (operand_equal_p (TYPE_SIZE (type),
TYPE_SIZE (TREE_TYPE (expr)));
       return wide_int_to_tree (type, wi::zext (wi::to_widest (expr),
TYPE_PRECISION (TREE_TYPE (expr)));
    }

but I realize IL verification around VIEW_CONVERTs is incomplete and
the above case
likely mostly happens with match.pd unifying the vector/non-vector
sign conversion path.

That said, the intent was to not have VIEW_CONVERT between types with
different precision
since on GIMPLE/GENERIC the off-precision bits have no representation
and thus cannot be
"converted" as unchanging.

Richard.


> +
>    /* We support up to 512-bit values (for V8DFmode).  */
>    unsigned char buffer[64];
>    int len;
> --
> 2.31.1
>