[cfe-dev] Implementing Altivec vector support questions

[Chris Lattner]

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  
MHO:

>
> 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  
> identifier.
> 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  
here :)

>
> 2. Regarding the typing, I'm thinking internally it would be treated  
> just as if __attribute__((vector_size(16)) were applied to the type,  
> right?

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  
> register?

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  
vector instructions.

-Chris