Hello, it would be nice to add sqrt to the gcc vector extensions. There are already target specific builtins, but a generic one would fit better (and get lowered to elementwise sqrt when the target doesn't support vector sqrt). I don't know if __builtin_sqrt should be extended, or maybe a different __builtin_vec_sqrt. Component "other" because fixing this might involve front, middle and back-ends.
Hmm, I suppose the extension would be to the C type-generic math piece. Of course that would require library support for most routines (and an ABI for them) or GCC, if no such routine is specified, expanding to a call for each vector component. Just special-casing sqrt may be convenient but odd. Joseph, any input?
Built-in mathematical functions are generally type-generic where they correspond to type-generic math.h macros (e.g. isgreater, isnan), not otherwise. (__builtin_signbit should be changed to type-generic: bug 36757.) I think __builtin_sqrt should be expected to correspond directly to the sqrt (double) library function rather than being type-generic - thus, I think vector versions of library functions (where those functions are not type-generic) should be separate from the normal built-in versions of those functions (e.g. define __builtin_vec_sqrt - which could itself be type-generic over different vector types). Remember to define, both at the language level and at the ABI level, things such as how such a built-in function handles errors / exceptional values (and whether or not this depends at the language level on the various -f options that affect this for ordinary C language arithmetic and library calls).
Thanks for the explanations. One goal would be, in C++, to be able to write a single function template: template<class T> T f(T x){return x+sqrt(x);} which would work for float, double, long double, float vectors and double vectors. (how exactly sqrt is spelled, possibly __builtin_math_sqrt, isn't that important) Currently, std::sqrt is overloaded on arithmetic types. If we had __builtin_vec_sqrt, I guess we could add an extra overload to std::sqrt for vector types (sfinae-constrained in some way). Not quite as convenient as a completely generic __builtin_sqrt, but good enough I think (assuming the libstdc++ maintainers are ok with it). Otherwise, a more generic __builtin_math_sqrt which works on both scalars and vectors would be better.
__builtin_tg_sqrt () maybe. The difficulty is in expected behavior for "standard" -O[0] when you supply vector arguments. I think the most "convenient" thing to do is to say that __builtin_tg_sqrt () when not invoked on scalar types can (but also might not) affect errno but in unpredictable ways. OTOH for sqrt the only documented errno is EDOM thus the result would be that errno is EDOM if at least one component caused a domain error. That would support lowering non-scalar variants to component-wise operation and also gives eventual support from math libraries the necessary freedom.