I'm working on PowerPC AltiVec support in clang. My strategy is to achieve correct IR generation for all AltiVec functions from corresponding GCC tests for AltiVec (altivec-1.c, altivec-2.c, ..) and then for the rest of the functions.
Currently added support for vec_add, vec_adds, vec_sub, vec_subs, vec_avg, vec_avg, vec_st and vec_all_eq. Sending patches, header & test. Please review.
altivec.h (8.56 KB)
builtins-pcc-altivec.c (4.68 KB)
BuiltinsPPC.patch (2.21 KB)
CGBuiltin.patch (4.4 KB)
CMakeLists.patch (283 Bytes)
Do we need builtins for the vector add / subtract / multiply / divide operations on AltiVec? Would it not be simpler to implement these in terms of the generic vector stuff in the header? This wasn't done in GCC because the generic vector support was added a couple of releases after the AltiVec code, but we don't have that legacy. It seems a little bit messy having two code paths in CodeGen for generating exactly the same IR for something as conceptually simple as addition.
We've already seen problems arising from having two independent code paths for generating constant selector expressions in Objective-C - I'd hate to see this kind of problem introduced elsewhere.
Do we need builtins for the vector add / subtract / multiply / divide operations on AltiVec?
Yes. We need to support gcc builtins regardless of altivec.h inclusion.
Would not the implicit inclusion of a header when -faltivec is passed (as is done with OpenCL) solve this problem?
-- Sent from my IBM 1620
Yep, this is the way to go. We don't want to add a bunch of builtins that should be defined in the header.