This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Vectorize conversions directly
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Dmitry Plotnikov <dplotnikov at ispras dot ru>
- Cc: gcc-patches at gcc dot gnu dot org, rearnsha at arm dot com, IRAR at il dot ibm dot com, dm at ispras dot ru
- Date: Wed, 24 Nov 2010 16:48:56 +0100
- Subject: Re: [PATCH] Vectorize conversions directly
- References: <4CED2DDC.firstname.lastname@example.org>
On Wed, Nov 24, 2010 at 4:23 PM, Dmitry Plotnikov <email@example.com> wrote:
> This patch enables vector conversions for ARM NEON architecture. ?In its
> current state vectorizer can't handle type conversions in the hottest loop
> of libmp3lame on NEON since its backend doesn't have appropriate builtins
> for type conversion. ?For x86_64 and rs6000 architectures that also can
> vectorize conversions the default behavior is retained. ?We have rewritten
> condition in vectorizable_conversion() in tree-vect-stmts.c for the case of
> NONE modifier. ?Now It first looks in convert_optab for suitable operation
> and then in builtins. ?It's hard to make such fix in arm backend, because
> neon builtins are not saved and enumerated as it's done for x86_64 and
> rs6000. ?Bootstrapped and regtested on x86_64 without any regressions.
> Ok for trunk? 4.7?
Hm. For proper LTO support you need to be able to index builtins
anyway, so I'd prefer if you fix the arm backend accordingly.
In general your patch requires adjusting the documentation of
FIX_TRUNC_EXPR and FLOAT_EXPR so that they also accept
vectors. I also expect various fallout in folders or optimization
passes if you allow that. So I don't think this patch is appropriate
for trunk at this stage.
I don't see a reason to not do this change for 4.7 though, so please
ping the patch when stage1 opens again. And still consider fixing
the arm backend ;)