This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [5/6] Insert pattern statements into vec_basic_blocks


On Wed, Aug 29, 2018 at 1:16 AM Jeff Law <law@redhat.com> wrote:
>
> On 08/28/2018 05:24 AM, Richard Sandiford wrote:
> > The point of this patch is to put pattern statements in the same
> > vec_basic_block as the statements they replace, with the pattern
> > statements for S coming between S and S's original predecessor.
> > This removes the need to handle them specially in various places.
> >
> >
> > 2018-08-28  Richard Sandiford  <richard.sandiford@arm.com>
> >
> > gcc/
> >       * tree-vectorizer.h (vec_basic_block): Expand comment.
> >       (_stmt_vec_info::pattern_def_seq): Delete.
> >       (STMT_VINFO_PATTERN_DEF_SEQ): Likewise.
> >       (is_main_pattern_stmt_p): New function.
> >       * tree-vect-loop.c (vect_determine_vf_for_stmt_1): Rename to...
> >       (vect_determine_vf_for_stmt): ...this, deleting the original
> >       function with this name.  Remove vectype_maybe_set_p argument
> >       and test is_pattern_stmt_p instead.  Retain the "examining..."
> >       message from the previous vect_determine_vf_for_stmt.
> >       (vect_compute_single_scalar_iteration_cost, vect_update_vf_for_slp)
> >       (vect_analyze_loop_2): Don't treat pattern statements specially.
> >       (vect_transform_loop): Likewise.  Use vect_orig_stmt to find the
> >       insertion point.
> >       * tree-vect-slp.c (vect_detect_hybrid_slp): Expect pattern statements
> >       to be in the statement list, without needing to follow
> >       STMT_VINFO_RELATED_STMT.  Remove PATTERN_DEF_SEQ handling.
> >       * tree-vect-stmts.c (vect_analyze_stmt): Don't handle pattern
> >       statements specially.
> >       (vect_remove_dead_scalar_stmts): Ignore pattern statements.
> >       * tree-vect-patterns.c (vect_set_pattern_stmt): Insert the pattern
> >       statement into the vec_basic_block immediately before the statement
> >       it replaces.
> >       (append_pattern_def_seq): Likewise.  If the original statement is
> >       itself a pattern statement, associate the new one with the original
> >       statement.
> >       (vect_split_statement): Use append_pattern_def_seq to insert the
> >       first pattern statement.
> >       (vect_recog_vector_vector_shift_pattern): Remove mention of
> >       STMT_VINFO_PATTERN_DEF_SEQ.
> >       (adjust_bool_stmts): Get the last pattern statement from the
> >       stmt_vec_info chain.
> >       (vect_mark_pattern_stmts): Rename to...
> >       (vect_replace_stmt_with_pattern): ...this.  Remove the
> >       PATTERN_DEF_SEQ handling and process only the pattern statement given.
> >       Use append_pattern_def_seq when replacing a pattern statement with
> >       another pattern statement, and use vec_basic_block::remove instead
> >       of gsi_remove to remove the old one.
> >       (vect_pattern_recog_1): Update accordingly.  Remove PATTERN_DEF_SEQ
> >       handling.  On failure, remove any half-formed pattern sequence from
> >       the vec_basic_block.  Install the vector type in pattern statements
> >       that don't yet have one.
> >       (vect_pattern_recog): Iterate over statements that are added
> >       by previous recognizers, but skipping those that have already
> >       been replaced, or the main pattern statement in such a replacement.
> Nice cleanup.  OK.

What I wonder is if this direction eventually allows us to get rid of all the
code that deals with pattern stmts not having SSA operands or immediate
uses?  Or is that already gone...?

Richard.

> jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]