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: [RFC][PATCH] New Vectorizer APIs


"Richard Guenther" <richard.guenther@gmail.com> wrote on 19/08/2008 
11:48:13:

> On Tue, Aug 19, 2008 at 10:04 AM, Razya Ladelsky <RAZYA@il.ibm.com> 
wrote:
> > Hi,
> >
> > This patch introduces new vectorizer functions that could be called 
from
> > other passes,
> > allowing the caller to obtain information about the vectorizability of 
a
> > loop, or the
> > costs of vectorizing it vs not vectorizing it.
> 
> Nice!
> 
> > The APIs I implemented are:
> > 1. loop_vectorizable_p  - tells whether the the loop is vectorizable.
> >
> > 2. get_min_prof_iters - returns minimum number of iterations
> > for which vectorization is profitable
> >
> > 3. get_int_sv_costs -  given an integer value representing the number 
of
> > iterations,
> > this function returns two integer parameters representing the scalar 
cost
> > and
> > the vectorized cost for the loop.
> >
> > 4. get_tree_sv_costs -  like get_int_sv_costs, only the number of
> > itreations is given as
> > a tree (it could be a symbolic expr), and the return values (scalar 
and
> > vector costs)
> > are also exprs depending on the numebr of iterations argument.
> 
> How expensive are these functions?  I think it makes sense to "cache"
> their outcome in the loop structure (given that in the end we want to
> retain it for the whole pass pipeline and not destroy/rebuild it all the
> time).
> 

Each function runs the whole vectorization analysis, and then computes 
the costs according to the analysis.

I think the main problem with caching them will be maintaining the 
information consistent.

> > We have a few ideas on potential passes that could benefit from using
> > these APIs to make their decisions.
> > One of our ideas is complete loop unrolling that occurs before the
> > vectorizer.
> 
> Certainly.  Though of course if we can say this loop is vectorizable
> at that point, why not vectorize it at that point?  Or are the cases
> where a loop is not vectorizable before complete unrolling but will
> become vectorizable at the point where the vectorizer runs uncommon?
> 

It depends on what loop you're examining.
You could look at different loop nests of a loop.
For example, you can compare the costs of vectorizing the inner loop, 
vs. vectorizing the outer loop, or unrolling the inner and then 
vectorizing (SLP)
the outer.
The idea is that you want to try and make the most profitable decision for 
transformation of 
loops, while taking vectorizability/profitability criteria into account. 
The vectorization transformation itself could be done at the point of 
decision, or
later at the vectorization pass. 



> Thanks,
> Richard.


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