This is the mail archive of the
mailing list for the GCC project.
Re: cost model patch
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Xinliang David Li <davidxl at google dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 26 Sep 2013 16:37:01 +0200
- Subject: Re: cost model patch
- Authentication-results: sourceware.org; auth=none
- References: <CAAkRFZ+_9YLa-EGF1xzrgW6QRh+So1bTo_njyjUPXj9S_t+jYw at mail dot gmail dot com>
On Thu, Sep 26, 2013 at 1:10 AM, Xinliang David Li <firstname.lastname@example.org> wrote:
> I took the liberty to pick up Richard's original fvect-cost-model
> patch and made some modification.
> What has not changed:
> 1) option -ftree-vect-loop-version is removed;
> 2) three cost models are introduced: cheap, dynamic, and unlimited;
> 3) unless explicitly specified, cheap model is the default at O2 (e.g.
> when -ftree-loop-vectorize is used with -O2), and dynamic mode is the
> default for O3 and FDO
> 4) alignment based versioning is disabled with cheap model.
> What has changed:
> 1) peeling is also disabled with cheap model;
> 2) alias check condition limit is reduced with cheap model, but not
> completely suppressed. Runtime alias check is a pretty important
> 3) tree if conversion changes are not included.
> Does this patch look reasonable?
In principle yes. Note that it changes the behavior of -O2 -ftree-vectorize
as -ftree-vectorize does not imply changing the default cost model. I am
fine with that, but eventually this will have some testsuite fallout. This
reorg would also need documenting in changes.html to make people
aware of this.
With completely disabling alingment peeling and alignment versioning
you cut out targets that have no way of performing unaligned accesses.
>From looking at vect_no_align this are mips, sparc, ia64 and some arm.
A compromise for them would be to allow peeling a single iteration
and some alignment checks (like up to two?).
Reducing the number of allowed alias-checks is ok, but I'd reduce it
more than to 6 (was that an arbitrary number or is that the result of
I suppose all of the params could use some benchmarking to select
a sweet spot in code size vs. runtime.
I suppose the patch is ok as-is (if it actually works) if you provide
a changelog and propose an entry for changes.html. We can
tune the params for the cheap model as followup.
Thanks for picking this up,