This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH PR77503]Record reduction code for CONST_COND_REDUCTION at analysis stage and use it at transform
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Bin Cheng <Bin dot Cheng at arm dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, nd <nd at arm dot com>
- Date: Thu, 15 Sep 2016 12:38:09 +0200
- Subject: Re: [PATCH PR77503]Record reduction code for CONST_COND_REDUCTION at analysis stage and use it at transform
- Authentication-results: sourceware.org; auth=none
- References: <VI1PR0802MB2176341761A63463372AB825E7F00@VI1PR0802MB2176.eurprd08.prod.outlook.com>
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.