This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, RFC, rs6000] Add overloaded built-in function support to altivec.h, and re-implement vec_add
- From: Bill Schmidt <wschmidt at linux dot vnet dot ibm dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Segher Boessenkool <segher at kernel dot crashing dot org>, David Edelsohn <dje dot gcc at gmail dot com>, willschm at vnet dot ibm dot com, Michael Meissner <meissner at linux dot vnet dot ibm dot com>
- Date: Mon, 31 Oct 2016 19:26:33 -0500
- Subject: Re: [PATCH, RFC, rs6000] Add overloaded built-in function support to altivec.h, and re-implement vec_add
- Authentication-results: sourceware.org; auth=none
- References: <4fb8f7f2-ff17-6416-3869-a8576c245dde@linux.vnet.ibm.com> <20161101000937.GO3541@tucnak.redhat.com>
> On Oct 31, 2016, at 7:09 PM, Jakub Jelinek <jakub@redhat.com> 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 only
>> expanded when they reach RTL. Our version of altivec.h currently defines the
>> public names of overloaded functions (like vec_add) to be #defines for hidden
>> functions (like __builtin_vec_add), which are recognized in the parser as
>> requiring special back-end support. Tables in rs6000-c.c handle dispatch of
>> the overloaded functions to specific function calls appropriate to the argument
>> types.
>
> This doesn't look very nice. If all you care is that the builtins like
> __builtin_altivec_vaddubm etc. that __builtin_vec_add overloads into fold
> into generic vector operations under certain conditions, just fold those
> into whatever you want in targetm.gimple_fold_builtin (gsi).
>
> Jakub
>
Ah, thanks, Jakub. I wasn't aware of that hook, and that sounds like the best
approach. I had found previously how difficult it can be to expand some of
these things during the parser hook, but if we can expand them early in
GIMPLE that is probably much easier. I will look into it.
"This doesn't look very nice" wins the understatement of the year award...
I was getting increasingly unhappy the further I got into it.
Thanks,
Bill