This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Have the scalarizer generate vectorizable loops.
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: Toon Moene <toon at moene dot indiv dot nluug dot nl>, paulthomas2 at wanadoo dot fr, fortran at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Wed, 04 Jan 2006 18:51:36 -0500
- Subject: Re: [RFC] Have the scalarizer generate vectorizable loops.
- References: <1136416912.10627.13.camel@IBM-82ZWS052TEN> <20060104234328.GA7278@atrey.karlin.mff.cuni.cz>
On Thu, 2006-01-05 at 00:43 +0100, Zdenek Dvorak wrote:
> Hello,
>
> > > > Zdenek already supplied a patch for it. That one didn't apply
> > > > completely cleanly, so I had to hand edit the result for one
> > > > chunk. The updated patch follows. It works in the sense that
> > > > it vectorizes the example I showed yesterday. I still have
> > > > to test it extensively (running make -k check, etc.).
> > >
> > > [ ... etc. ... ]
> > >
> > > It passed make -k check with no additional regressions.
> > >
> > > Who can approve this patch ? Sebastian ? DannyB ?
> >
> > I looked at the patch, and it looks fine to me, although it does look
> > like this code is getting a bit messy.
> >
> > (Personally, I think we should be using SCEV more heavily than we do
> > now, instead of making up affine style expressions everywhere, like loop
> > strength reduction)
>
> the reason for this is that ivopts and # of iteration analysis only work
> with affine ivs,
> and having to wrap and unwrap the components from
> CHRECs would be quite cumbersome (and wasting memory).
You are joking, right?
It ends up looking something like ComputeIterationCount* in
http://llvm.cs.uiuc.edu/cvsweb/cvsweb.cgi/llvm/lib/Analysis/ScalarEvolution.cpp?rev=1.44&content-type=text/x-cvsweb-markup
This code looks a heck of a lot nicer than the weird mix of stuff we
have.
> Or do you have
> something else in mind?
Not having affine expressions, SCEV, affine combinations, and 3 other
representations of things we could simply represent all the same way?
>
> Zdenek
>