> -----Original Message-----
> From: Richard Sandiford <richard.sandif...@arm.com>
> Sent: 27 November 2020 08:29
> To: Richard Biener <richard.guent...@gmail.com>
> Cc: Kyrylo Tkachov <kyrylo.tkac...@arm.com>; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] aarch64: Introduce --param=aarch64-autovec-
> preference to select autovec preference in backend
> 
> Richard Biener <richard.guent...@gmail.com> writes:
> > On Thu, Nov 26, 2020 at 6:18 PM Kyrylo Tkachov via Gcc-patches
> > <gcc-patches@gcc.gnu.org> wrote:
> >>
> >> Hi all,
> >>
> >> This is a patch that introduces the aarch64-autovec-preference that can
> take values from 0 - 4, 0 being the default.
> >> It can be used to override the autovectorisation preferences in the
> backend:
> >> 0 - use default scheme
> >> 1 - only use Advanced SIMD
> >> 2 - only use SVE
> >> 3 - use Advanced SIMD and SVE, prefer Advanced SIMD in the event of a
> tie (as determined by costs)
> >> 4 - use Advanced SIMD and SVE, prefer SVE in the event of a tie (as
> determined by costs)
> >>
> >> It can valuable for experimentation when comparing SVE and Advanced
> SIMD autovectorisation strategies.
> >>
> >> It achieves this adjusting the order of the interleaved SVE and Advanced
> SIMD modes in aarch64_autovectorize_vector_modes.
> >> It also adjusts aarch64_preferred_simd_mode to use the new comparison
> function to pick Advanced SIMD or SVE to start with.
> >>
> >> Bootstrapped and tested on aarch64-none-linux-gnu.
> >> Ok for master (since it touches much SVE-related code by Richard I'd feel
> more comfortable with a second pair of eyes)?
> 
> LGTM.

Thanks, I've pushed it to master.
It also applies cleanly and bootstrap and testing on GCC 10 branch looks ok.
Is it okay to backport it there as well?

> 
> > Is this supposed to be used internally or for development purposes?
> > If users are supposed
> > to use this then a -m switch would be more appropriate (x86 for example
> has
> > -mprefer-vector-width)
> 
> I think it's more production vs. experimentation rather than developer
> vs. user.  Users shouldn't have to worry about this kind of thing when
> they're doing production builds: specifying -mcpu or -mtune should
> be enough to get the right behaviour.  But having a --param like this
> that we can point users at is useful for getting feedback or as an
> interim workaround until an optimisation bug is fixed.  And like you
> say, it's also useful for running experiments for development.

Indeed. I think eventually the compiler should be smart enough to transparently 
pick and mix SVE and Advanced SIMD
for a given -mcpu/-mtune, I wouldn't want production users to view this param 
as a long-term recommendation.

Thanks,
Kyrill

> 
> Thanks,
> Richard

Reply via email to