This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [5/n] PR85694: Remove dead WIDEN_SUM handling
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: GCC Patches <gcc-patches at gcc dot gnu dot org>, richard dot sandiford at arm dot com
- Date: Tue, 19 Jun 2018 11:57:15 +0200
- Subject: Re: [5/n] PR85694: Remove dead WIDEN_SUM handling
- References: <8736xkgn2a.fsf@arm.com>
On Mon, Jun 18, 2018 at 4:57 PM Richard Sandiford
<richard.sandiford@arm.com> wrote:
>
> vect_recog_dot_prod_pattern and vect_recog_sad_pattern both checked
> whether the statement passed in had already been recognised as a
> WIDEN_SUM_EXPR pattern. That isn't possible (any more?), since the
> first recognised pattern wins, and since vect_recog_widen_sum_pattern
> never matches a later statement than the one it's given.
And after my just committed patch we'll never try any further pattern
recognition on a stmt already recognized as pattern.
> Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
OK.
Richard.
> Richard
>
>
> 2018-06-18 Richard Sandiford <richard.sandiford@arm.com>
>
> gcc/
> * tree-vect-patterns.c (vect_recog_dot_prod_pattern): Remove
> redundant WIDEN_SUM_EXPR handling.
> (vect_recog_sad_pattern): Likewise.
>
> Index: gcc/tree-vect-patterns.c
> ===================================================================
> *** gcc/tree-vect-patterns.c 2018-06-18 15:56:12.908496017 +0100
> --- gcc/tree-vect-patterns.c 2018-06-18 15:56:12.904496052 +0100
> *************** vect_recog_dot_prod_pattern (vec<gimple
> *** 339,375 ****
> return NULL;
>
> if (STMT_VINFO_IN_PATTERN_P (stmt_vinfo))
> ! {
> ! /* Has been detected as widening-summation? */
>
> ! stmt = STMT_VINFO_RELATED_STMT (stmt_vinfo);
> ! type = gimple_expr_type (stmt);
> ! if (gimple_assign_rhs_code (stmt) != WIDEN_SUM_EXPR)
> ! return NULL;
> oprnd0 = gimple_assign_rhs1 (stmt);
> - oprnd1 = gimple_assign_rhs2 (stmt);
> - half_type = TREE_TYPE (oprnd0);
> }
> else
> ! {
> ! gimple *def_stmt;
> !
> ! if (!vect_reassociating_reduction_p (stmt_vinfo))
> ! return NULL;
> ! oprnd0 = gimple_assign_rhs1 (last_stmt);
> ! oprnd1 = gimple_assign_rhs2 (last_stmt);
> ! stmt = last_stmt;
> !
> ! if (type_conversion_p (oprnd0, stmt, true, &half_type, &def_stmt,
> ! &promotion)
> ! && promotion)
> ! {
> ! stmt = def_stmt;
> ! oprnd0 = gimple_assign_rhs1 (stmt);
> ! }
> ! else
> ! half_type = type;
> ! }
>
> /* So far so good. Since last_stmt was detected as a (summation) reduction,
> we know that oprnd1 is the reduction variable (defined by a loop-header
> --- 339,363 ----
> return NULL;
>
> if (STMT_VINFO_IN_PATTERN_P (stmt_vinfo))
> ! return NULL;
>
> ! if (!vect_reassociating_reduction_p (stmt_vinfo))
> ! return NULL;
> !
> ! oprnd0 = gimple_assign_rhs1 (last_stmt);
> ! oprnd1 = gimple_assign_rhs2 (last_stmt);
> ! stmt = last_stmt;
> !
> ! gimple *def_stmt;
> ! if (type_conversion_p (oprnd0, stmt, true, &half_type, &def_stmt,
> ! &promotion)
> ! && promotion)
> ! {
> ! stmt = def_stmt;
> oprnd0 = gimple_assign_rhs1 (stmt);
> }
> else
> ! half_type = type;
>
> /* So far so good. Since last_stmt was detected as a (summation) reduction,
> we know that oprnd1 is the reduction variable (defined by a loop-header
> *************** vect_recog_sad_pattern (vec<gimple *> *s
> *** 553,586 ****
> tree plus_oprnd0, plus_oprnd1;
>
> if (STMT_VINFO_IN_PATTERN_P (stmt_vinfo))
> ! {
> ! /* Has been detected as widening-summation? */
>
> ! gimple *stmt = STMT_VINFO_RELATED_STMT (stmt_vinfo);
> ! sum_type = gimple_expr_type (stmt);
> ! if (gimple_assign_rhs_code (stmt) != WIDEN_SUM_EXPR)
> ! return NULL;
> ! plus_oprnd0 = gimple_assign_rhs1 (stmt);
> ! plus_oprnd1 = gimple_assign_rhs2 (stmt);
> ! half_type = TREE_TYPE (plus_oprnd0);
> ! }
> ! else
> ! {
> ! gimple *def_stmt;
>
> ! if (!vect_reassociating_reduction_p (stmt_vinfo))
> ! return NULL;
> ! plus_oprnd0 = gimple_assign_rhs1 (last_stmt);
> ! plus_oprnd1 = gimple_assign_rhs2 (last_stmt);
>
> ! /* The type conversion could be promotion, demotion,
> ! or just signed -> unsigned. */
> ! if (type_conversion_p (plus_oprnd0, last_stmt, false,
> ! &half_type, &def_stmt, &promotion))
> ! plus_oprnd0 = gimple_assign_rhs1 (def_stmt);
> ! else
> ! half_type = sum_type;
> ! }
>
> /* So far so good. Since last_stmt was detected as a (summation) reduction,
> we know that plus_oprnd1 is the reduction variable (defined by a loop-header
> --- 541,562 ----
> tree plus_oprnd0, plus_oprnd1;
>
> if (STMT_VINFO_IN_PATTERN_P (stmt_vinfo))
> ! return NULL;
>
> ! if (!vect_reassociating_reduction_p (stmt_vinfo))
> ! return NULL;
>
> ! plus_oprnd0 = gimple_assign_rhs1 (last_stmt);
> ! plus_oprnd1 = gimple_assign_rhs2 (last_stmt);
>
> ! /* The type conversion could be promotion, demotion,
> ! or just signed -> unsigned. */
> ! gimple *def_stmt;
> ! if (type_conversion_p (plus_oprnd0, last_stmt, false,
> ! &half_type, &def_stmt, &promotion))
> ! plus_oprnd0 = gimple_assign_rhs1 (def_stmt);
> ! else
> ! half_type = sum_type;
>
> /* So far so good. Since last_stmt was detected as a (summation) reduction,
> we know that plus_oprnd1 is the reduction variable (defined by a loop-header
> *************** vect_recog_sad_pattern (vec<gimple *> *s
> *** 639,645 ****
> return NULL;
>
> tree half_type0, half_type1;
> - gimple *def_stmt;
>
> tree minus_oprnd0 = gimple_assign_rhs1 (diff_stmt);
> tree minus_oprnd1 = gimple_assign_rhs2 (diff_stmt);
> --- 615,620 ----