On Tue, 2016-04-19 at 08:10 -0500, Bill Schmidt wrote: > On Tue, 2016-04-19 at 10:09 +0200, Richard Biener wrote: > > > > x86 nowadays has intrinsics implemented as inlines - they come from > > header files. It seems for ppc the intrinsics are somehow magically > > there, w/o a header file? > > Yes, and we really need to start gravitating to the inlines in header > files model (Clang does this successfully for PowerPC and it is quite a > bit cleaner, and allows for more optimization). We have a very > complicated setup for handling overloaded built-ins that could use a > rewrite once somebody has time to attack it. We do have one header file > for built-ins (altivec.h) but it largely just #defines well-known > aliases for the internal built-in names. We have a lot of other things > we have to do in GCC 7, but I'd like to do something about this in the > relatively near future. (Things like "vec_add" that just do a vector > addition aren't expanded until RTL time?? Gack.)
Looking into this a bit more reminded me why things are the way they are. The AltiVec interfaces were designed way back to be overloaded functions, which isn't valid C99. Thus they can't be declared in headers without some magic. Clang solved this by adding an extension __attribute__ ((__overloaded__)), which allows nice always-inline functions that fully express the semantics and integrate well into the optimizers. To date, GCC doesn't have such an attribute. Thus we have this somewhat nasty code that gets called out of the front end that allows us to resolve the overloaded built-ins during parsing. With C11 we could use _Generic, but having two separate interfaces to maintain based on the language level doesn't seem reasonable. It looks like there is a way to do this with GCC built-ins, however, using __builtin_choose_expr and __builtin_types_compatible_p (https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html). I need to play with this and see what kind of code gets generated. If we end up with a bunch of run-time type checks that would still not be a good solution. I wonder how hard it would be to get support for __attribute__ ((__overloaded__)) in GCC... Thanks again, Bill
