ping
________________________________________
From: Wilco Dijkstra
Sent: 16 December 2015 11:37
To: Richard Biener; James Greenhalgh
Cc: GCC Patches; nd
Subject: RE: [PATCH][AArch64] Add vector permute cost
Richard Biener wrote:
> On Wed, Dec 16, 2015 at 10:32 AM, James Greenhalgh
> <james.greenha...@arm.com> wrote:
> > On Tue, Dec 15, 2015 at 11:35:45AM +0000, Wilco Dijkstra wrote:
> >>
> >> Add support for vector permute cost since various permutes can expand into
> >> a complex
> >> sequence of instructions. This fixes major performance regressions due to
> >> recent changes
> >> in the SLP vectorizer (which now vectorizes more aggressively and emits
> >> many complex
> >> permutes).
> >>
> >> Set the cost to > 1 for all microarchitectures so that the number of
> >> permutes is usually zero
> >> and regressions disappear. An example of the kind of code that might be
> >> emitted for
> >> VEC_PERM_EXPR {0, 3} where registers happen to be in the wrong order:
> >>
> >> adrp x4, .LC16
> >> ldr q5, [x4, #:lo12:.LC16
> >> eor v1.16b, v1.16b, v0.16b
> >> eor v0.16b, v1.16b, v0.16b
> >> eor v1.16b, v1.16b, v0.16b
> >> tbl v0.16b, {v0.16b - v1.16b}, v5.16b
> >>
> >> Regress passes. This fixes regressions that were introduced recently, so
> >> OK for commit?
> >>
> >>
> >> ChangeLog:
> >> 2015-12-15 Wilco Dijkstra <wdijk...@arm.com>
> >>
> >> * gcc/config/aarch64/aarch64.c (generic_vector_cost):
> >> Set vec_permute_cost.
> >> (cortexa57_vector_cost): Likewise.
> >> (exynosm1_vector_cost): Likewise.
> >> (xgene1_vector_cost): Likewise.
> >> (aarch64_builtin_vectorization_cost): Use vec_permute_cost.
> >> * gcc/config/aarch64/aarch64-protos.h (cpu_vector_cost):
> >> Add vec_permute_cost entry.
> >>
> >>
> >> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> >> index
> >> 10754c88c0973d8ef3c847195b727f02b193bbd8..2584f16d345b3d015d577dd28c08a73ee3e0b0fb
> >> 100644
> >> --- a/gcc/config/aarch64/aarch64.c
> >> +++ b/gcc/config/aarch64/aarch64.c
> >> @@ -314,6 +314,7 @@ static const struct cpu_vector_cost
> >> generic_vector_cost =
> >> 1, /* scalar_load_cost */
> >> 1, /* scalar_store_cost */
> >> 1, /* vec_stmt_cost */
> >> + 2, /* vec_permute_cost */
> >> 1, /* vec_to_scalar_cost */
> >> 1, /* scalar_to_vec_cost */
> >> 1, /* vec_align_load_cost */
> >
> > Is there any reasoning behind making this 2? Do we now miss vectorization
> > for some of the cheaper permutes? Across the cost models/pipeline
> > descriptions that have been contributed to GCC I think that this is a
> > sensible change to the generic costs, but I just want to check there
> > was some reasoning/experimentation behind the number you picked.
Yes, it blocks vectorization if they have a high percentage of permutes, even
if trivial.
But that is exactly the goal - when we vectorize we want to minimize data
shuffling
that just adds latency and does not contribute to actual work.
The value 2 was the minimal value that avoided the regressions I noticed due the
improved SLP vectorization. I tried other possibilities like increasing the
statement cost,
but that affects other cases, so this is the simplest change.
Note that I'm not too convinced about any of the existing vector costs, they
seem
fairly random numbers - the A57 vector costs for example block many simple
vectorization cases that are beneficial. The goal of this is simply to fix the
regressions
rather than tuning vector costs (which is only possible if we have a better
cost model).
> > As permutes can have such wildly different costs, this all seems like a good
> > candidate for some future much more involved hook from the vectorizer to the
> > back-end specifying the candidate permute operation and requesting a cost
> > (part of the bigger gimple costs framework?).
>
> Yes, the vectorizer side also needs to improve here. Not sure if it is
> possible
> to represent this kind of complex cost queries with a single gimple cost hook.
> After all we don't really want to generate the full gimple stmt just to query
> its cost ...
>
> To better represent permute cost in the short term we'd need another
> vectorizer
> specific hook, not sth for stage3 unless we face some serious regressions
> on real-world code (thus not microbenchmarks only)
Yes we need a better cost model for the vectorizer. The sort of things that are
important
is the vector mode (so we can differentiate between 2x, 4x, 8x, 16x
vectorization etc),
the specific permute for permutes, the size and type of load/store (as some do
permutes) etc.
Wilco
