fold: Optimise fold_view_convert_expr
Commit Message
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(+)
Comments
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
>
@@ -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));
+
/* We support up to 512-bit values (for V8DFmode). */
unsigned char buffer[64];
int len;