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: [PATCH PR77503]Record reduction code for CONST_COND_REDUCTION at analysis stage and use it at transform


On Thu, Sep 15, 2016 at 12:07 PM, Bin Cheng <Bin.Cheng@arm.com> wrote:
> Hi,
> This patch fixes PR77503.  Root cause is loop peeling changes the initial value for reduction PHI node, resulting in different statement for vect_transform_stmt to vect_analyze_stmt.  Similar issue stands for loop control IV, we record the original information in LOOP_PHI_EVOLUTION_BASE_UNCHANGED for that.  This patch follows the same method by recording reduction code for CONST_COND_REDUCTION at analysis stage and use the information at transform stage.  The only difference is we need record it in stmt_vec_info because there might be multiple reductions.  Unfortunately this requires additional memory for each statement, I didn't see easy way out.  Maybe it's possible to improve vectorizer so it caches/reuses information from analysis stage to transform stage?
> Bootstrap and test on x86_64 and AArch64 ongoing.  Is it OK if no regression?

Ok.

As for improving stmt_info size and caching info from analysis phase
-- yes, ideally stmt_info would have
most of its contents discriminated on STMT_VINFO_TYPE using a union of
type specific fields.  Note that
this kind of refactoring would be way easier than trying to make it a
class using inheritance (you'd need to
defer vinfo creation until analysis figured out the info or add an
indirection to type specific data).

stmt_info isn't very well packed either so the general answer for now
is -- we don't care about its size.

As for re-using data from analysis phase -- yes!  That we share the
"head" of all vectorizable_* routines
for both analysis and transform phase was a bad design decision --
ideally we'd have vectorizable_*
routines w/o transform and then vectorize_* routines which only do the
transform based on data recorded
during analysis phase.

Both refactorings are very welcome (esp. the latter which eventually
means adding many more fields to
stmt_info).

Thanks,
Richard.

> Thanks,
> bin
>
> 2016-09-07  Bin Cheng  <bin.cheng@arm.com>
>
>         PR tree-optimization/77503
>         * tree-vect-loop.c (vectorizable_reduction): Record reduction
>         code for CONST_COND_REDUCTION at analysis stage and use it at
>         transform stage.
>         * tree-vectorizer.h (struct _stmt_vec_info): New field.
>         (STMT_VINFO_VEC_CONST_COND_REDUC_CODE): New macro.
>         * tree-vect-stmts.c (new_stmt_vec_info): Initialize above new
>         field.
>
> gcc/testsuite/ChangeLog
> 2016-09-07  Bin Cheng  <bin.cheng@arm.com>
>
>         PR tree-optimization/77503
>         * gcc.dg/vect/pr77503.c: New test.


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