This is the mail archive of the 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: [RFC][vect]PR: 65930 teach vectorizer to handle SUM reductions with sign-change casts

On Tue, 27 Aug 2019, Richard Biener wrote:

> On Fri, 23 Aug 2019, Andre Vieira (lists) wrote:
> > Hi Richard,
> > 
> > I have come up with a way to teach the vectorizer to handle sign-changing
> > reductions, restricted to SUM operations as I'm not sure other reductions are
> > equivalent with different signs.
> > 
> > The main nature of this approach is to let it recognize reductions of the
> > form: Phi->NopConversion?->Plus/Minus-reduction->NopConversion?->Phi. Then
> > vectorize the statements normally, with some extra workarounds to handle the
> > conversions. This is mainly needed where it looks for uses of the result of
> > the reduction, we now need to check the uses of the result of the conversion
> > instead.
> > 
> > I am curious to know what you think of this approach. I have regression tested
> > this on aarch64 and x86_64 with AVX512 and it shows no regressions. On the 1
> > month old version of trunk I tested on it even seems to make
> > gcc.dg/vect/pr89268.c pass, where it used to fail with an ICE complaining
> > about a definition not dominating a use.
> Aww.  Yeah, I had a half-way working patch along this line as well
> and threw it away because of ugliness.
> So I was hoping we can at some point refactor the reduction detection
> code to use the path discovery in check_reduction_path (which is basically
> a lame SCC finding algorithm), massage the detected reduction path
> and in the reduction PHI meta-data record something like
> "this reduction SUMs _1, _4, _3 and _5" plus for the conversions
> "do the reduction in SIGN" and during code-generation just look at
> the PHI node and the backedge def which we'd replace.
> But of course I stopped short trying that because the reduction code
> is a big mess.  And I threw away the attempt that looked like yours
> because I didn't want to make an even bigger mess out of it :/
> On the branch throwing away the non-SLP paths I started to 
> refactor^Wrewrite all this but got stuck as well.

Before you start looking I figured this all is only in my
working tree...


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