Re: [PATCH, RFC, rs6000] Add overloaded built-in function support to altivec.h, and re-implement vec_add

On Nov 2, 2016, at 4:28 AM, Jakub Jelinek wrote: > > On Wed, Nov 02, 2016 at 10:19:26AM +0100, Richard Biener wrote: >> On Tue, Nov 1, 2016 at 1:09 AM, Jakub Jelinek wrote: >>> On Mon, Oct 31, 2016 at 05:28:42PM -0500, Bill Schmidt wrote: The PowerPC

Re: [PATCH, RFC, rs6000] Add overloaded built-in function support to altivec.h, and re-implement vec_add

On Wed, Nov 02, 2016 at 10:19:26AM +0100, Richard Biener wrote: > On Tue, Nov 1, 2016 at 1:09 AM, Jakub Jelinek wrote: > > On Mon, Oct 31, 2016 at 05:28:42PM -0500, Bill Schmidt wrote: > >> The PowerPC back end loses performance on vector intrinsics, because > >> currently > >>

Re: [PATCH, RFC, rs6000] Add overloaded built-in function support to altivec.h, and re-implement vec_add

On Tue, Nov 1, 2016 at 1:09 AM, Jakub Jelinek wrote: > On Mon, Oct 31, 2016 at 05:28:42PM -0500, Bill Schmidt wrote: >> The PowerPC back end loses performance on vector intrinsics, because >> currently >> all of them are treated as calls throughout the middle-end phases and

Re: [PATCH, RFC, rs6000] Add overloaded built-in function support to altivec.h, and re-implement vec_add

Hello, how far are we from being able to use #define vec_add(a,b) ((a)+(b)) ? The few tests I tried pass with -flax-vector-conversions, and the only ones that require this flag are those involving vector bool XXX. Would it make sense to tweak the front-ends to do the right thing for those

Re: [PATCH, RFC, rs6000] Add overloaded built-in function support to altivec.h, and re-implement vec_add

On Oct 31, 2016, at 7:19 PM, Michael Meissner wrote: > > One question is how many of the billions and billions (ok, 1,345) of the > rs6000 > built-ins would be improved by expanding them in gimple time rather than rtl? > Hundreds and hundreds of them. All of the

Re: [PATCH, RFC, rs6000] Add overloaded built-in function support to altivec.h, and re-implement vec_add

> On Oct 31, 2016, at 7:09 PM, Jakub Jelinek wrote: > > On Mon, Oct 31, 2016 at 05:28:42PM -0500, Bill Schmidt wrote: >> The PowerPC back end loses performance on vector intrinsics, because >> currently >> all of them are treated as calls throughout the middle-end phases and

Re: [PATCH, RFC, rs6000] Add overloaded built-in function support to altivec.h, and re-implement vec_add

On Mon, Oct 31, 2016 at 06:49:20PM -0500, Bill Schmidt wrote: > > > > On Oct 31, 2016, at 5:28 PM, Bill Schmidt > > wrote: > > > > The other way would be to require a specific option on the command line > > to use the new dispatch mechanism. When the option is

Re: [PATCH, RFC, rs6000] Add overloaded built-in function support to altivec.h, and re-implement vec_add

On Mon, Oct 31, 2016 at 05:28:42PM -0500, Bill Schmidt wrote: > The PowerPC back end loses performance on vector intrinsics, because currently > all of them are treated as calls throughout the middle-end phases and only > expanded when they reach RTL. Our version of altivec.h currently defines

Re: [PATCH, RFC, rs6000] Add overloaded built-in function support to altivec.h, and re-implement vec_add

> > On Oct 31, 2016, at 5:28 PM, Bill Schmidt wrote: > > The other way would be to require a specific option on the command line > to use the new dispatch mechanism. When the option is present, we would > predefine a macro such as __PPC_FAST_VECTOR__, which

[PATCH, RFC, rs6000] Add overloaded built-in function support to altivec.h, and re-implement vec_add

Hi, The PowerPC back end loses performance on vector intrinsics, because currently all of them are treated as calls throughout the middle-end phases and only expanded when they reach RTL. Our version of altivec.h currently defines the public names of overloaded functions (like vec_add) to be