This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Merging Graphite to trunk
On Sun, 2 Aug 2009, Albert Cohen wrote:
> Sebastian Pop wrote:
> > On Sun, Aug 2, 2009 at 03:14, Ira Rosen<IRAR@il.ibm.com> wrote:
> > > > Another
> > > > problem that is still not fixed is the bb and edges frequencies and
> > > > probabilities that are for the moment not set up correctly, making all
> > > > the loops generated by Graphite look like "cold loops", and the cost
> > > > model of the vectorizer just discards those loops.
> > > Could you please explain this more or give an example?
> >
> > In create_empty_loop_on_edge we have this code:
> >
> > /* TODO: Fix frequencies and counts. */
> > freq = EDGE_FREQUENCY (entry_edge);
> > cnt = entry_edge->count;
> >
> > prob = REG_BR_PROB_BASE / 2;
> >
> > scale_loop_frequencies (loop, REG_BR_PROB_BASE - prob, REG_BR_PROB_BASE);
> >
> > In tree-vectorizer.c:vectorize_loops you use maybe_hot_bb_p via a call
> > to optimize_loop_nest_for_speed_p:
> >
> > FOR_EACH_LOOP (li, loop, 0)
> > if (optimize_loop_nest_for_speed_p (loop))
> > ...
> >
> > /* Return true in case BB can be CPU intensive and should be optimized
> > for maximal performance. */
> >
> > bool
> > maybe_hot_bb_p (const_basic_block bb)
> > {
> > if (profile_status == PROFILE_READ)
> > return maybe_hot_count_p (bb->count);
> > return maybe_hot_frequency_p (bb->frequency);
> > }
> >
> > As long as create_empty_loop_on_edge does not set bb->count and
> > bb->frequency correctly the vectorizer won't trigger on the loops that
> > Graphite code generates.
> >
> > Sebastian
>
> Thank you Sebastian.
>
> In the short term, it is certainly sufficient to replace the loop entry
> freq/cnt with high-enough constants that will trigger vectorization (even for
> prolog/epilog code, but it should not impact performance).
>
> The longer term approach is probably to completely replace the cost model of
> the vectorizer with a Graphite-based one, following the approach of our
> PACT'09 paper (Ira is a co-author). Vectorization hints will then be passed
> through the loop_info. It is on the TODO list of Konrad Trifunovic to rework
> our prototype into a robust version.
You should be able to get edge frequencies from the edges coming into
the SCoPs and then after going out-of-graphite do what the profile
estimation does based on that values. Or even more simple - re-run
the profile estimates on the whole function body.
Note that the profiles not only affect vectorization but also
expansion and rtl optimizers.
Richard.