This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] (2/3) Add vectorization of builtin functions
- From: Richard Guenther <rguenther at suse dot de>
- To: Dorit Nuzman <DORIT at il dot ibm dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>, pinskia at gcc dot gnu dot org
- Date: Sat, 18 Nov 2006 19:30:02 +0100 (CET)
- Subject: Re: [PATCH] (2/3) Add vectorization of builtin functions
- References: <OFB42D418D.7308FC43-ON4225722A.0062C5C2-4225722A.0063E599@il.ibm.com>
On Sat, 18 Nov 2006, Dorit Nuzman wrote:
> > On Thu, 16 Nov 2006, Dorit Nuzman wrote:
> >
> > > >
> > > > This adds vectorization of builtin functions to the vectorizer. It
> does
> > >
> > > looks good to me...
> >
> > This patch^Whack on top of it enables vectorization of lrint.
> >
> ...
> >
> >
> > just as an example - the x86 builtins need to survive in an array
> > to be accessible later. We also need to address that most of the
> > x86 SSE builtins lack const or pure attributes (so the DECL_NOVOPS
> > hack ontop of the keep the decl hack ;)).
> >
>
> I think that we have the same problem with the Altivec builtins, and that
> Andrew Pinski is going to fix this (
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29779#c5)
Yes, I have done a i386 patch here:
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01275.html
> > Just FYI... (we might be able to avoid too many new tree-codes by
> > resorting to builtins where appropriate)
> >
>
> the trade-off is having function calls in the code, which may hinder some
> optimizations (?). Available tree-codes is indeed a problem, but probably
> the solution is to increase it...
As vectorization is late in the tree-optimizer pipeline it might not
be that bad. New tree-codes also have to be supported somehow by the
optimizers, so as long as the functions are const there should be no
penalty here.
Richard.
--
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs