On Nov 2, 2016, at 4:28 AM, Jakub Jelinek <ja...@redhat.com> 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 <ja...@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). >> >> Note that traditionally "overloading" with GCC "builtins" is done by >> using varargs >> and the "type generic" attribute. That doesn't scale to return type >> overloading >> though for which we usually added direct support to the parser (for example >> for __builtin_shuffle). > > My understanding is that rs6000 already does that, it hooks into > resolve_overloaded_builtin which already handles the fully type generic > builtins where not just the arguments, but also the return type can be > picked up. But it resolves the overloaded builtins into calls to other > builtins that are not type-generic. > > So, either that function instead of returning the specific md builtin calls > in some cases already returns trees with the generic behavior of the > builtin, or it returns what it does now and then in the gimple fold builtin > target hook (note, the normal fold builtin target hook is not right for > that, because it is mostly used for folding builtins into constant - callers > will usually throw away other results) fold those specific md builtins > into whatever GIMPLE you want. If we want to decrease amount of folding in > the FEs, the gimple fold builtin hook is probably better. > > Jakub
Thanks, all. Using the gimple_fold_builtin target hook works very well and is exactly what I'm looking for. I've reworked the patch to the much simpler https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00104.html. Much obliged for the help! Bill
