This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC][PATCH] New Vectorizer APIs
- From: Razya Ladelsky <RAZYA at il dot ibm dot com>
- To: "Richard Guenther" <richard dot guenther at gmail dot com>
- Cc: Dorit Nuzman <DORIT at il dot ibm dot com>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 19 Aug 2008 12:58:09 +0300
- Subject: 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.