[cfe-dev] Implementing Altivec vector support questions
clattner at apple.com
Tue Dec 8 10:47:20 PST 2009
On Dec 7, 2009, at 12:55 PM, John Thompson wrote:
> 1. In implementing vector and __vector, which is better?:
I'm not familiar with the intricacies of this extension, so I don't
know the technical feasibility of the different approaches, but here's
> A. Don't make it a keyword, but if LangOptions::AltiVec is set and
> a kw_identifier with the name "vector" or "__vector" is followed by
> a numeric type keyword, make the type a vector type.
This would be the "context sensitive keyword" approach I guess. I
tend to not like this because it can be fragile / unpredictable.
> B. Make vector and __vector a keyword if LangOptions::AltiVec is
> set, and if not followed by a numeric type keyword, treat it as an
> My guess is that A is better as it involves less fixing up of cases
> where an identifier with the name of "vector" can occur.
I don't know how much magic is inherent in this language extension.
Would it be bad to to make __vector *always* be on when AltiVec is
enabled (whether or not it is followed by a 'numeric type keyword')?
We could then make 'vector' be fuzzier. I'm still vaguely
uncomfortable with 'vector' changing semantics depending on its
lexical context, but understand that you probably don't have a choice
> 2. Regarding the typing, I'm thinking internally it would be treated
> just as if __attribute__((vector_size(16)) were applied to the type,
Sure, if that works! I don't know what __vector does.
> 3. With __attribute__((vector_size(16)), does the Clang code
> generation already output everything LLVM needs to support the
> Altivec vectors?
I think so, though we also need an 'altivec.h' for clang to use, in a
similar spirit to 'xmmintrin.h' for sse.
> For example, in looking at the code generated for some code using an
> "__attribute__((vector_size(16)) float" variable or return type,
> the .ll file uses "<4 x float>". On a PowerPC platform supporting
> Altivec, does LLVM automatically know to map that to a vector
Yes. However, noone has done any ABI compatibility testing on
PowerPC, even for simple types. It is likely that there are a bunch
of bugs passing structures by value etc. Daniel has a nice randomized
testcase generator for finding cases that need to be improved.
> 4. I'm guessing the Altivec functions can be implemented as Clang
> built-in functions that map to calls to LLVM's altivec intrinsic
> functions, right? I haven't researched this much yet.
Yes, we support the 'unusual' altivec builtins in llvm-gcc by mapping
them onto the LLVM intrinsics in llvm/include/llvm/
IntrinsicsPowerPC.td. The simple ones make directly onto llvm IR
More information about the cfe-dev