[cfe-dev] Implementing Altivec vector support questions

[John Thompson]

 Thanks, Chris.


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

I think I see.  Treat "__vector" as a normal keyword token, and if "vector"
is encountered, I still do the context check and effectively treat it as
"__vector"?


> Sure, if that works!  I don't know what __vector does.
>

My understanding is that "__vector" (or "vector") in this context is always
followed by a numeric type, i.e. "_vector unsigned int".  My guess was that
this would be effecticvely equivalent to "__attribute__((vector_size(16)))
unsigned int", so the plan would then be to have the resulting type for
these two be the same after the semantic action.

> I think so, though we also need an 'altivec.h' for clang to use, in a
> similar spirit to 'xmmintrin.h' for sse.
>

Yes, probably, if nothing else just to be compatible with gcc.  (It's
mentioned in the Altivec standard in section 2.6 of
http://www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf).  I was
told it was orginally deprecated, but then left in to help with early
implementation.  Looking at the one we have for the PS3 gcc compiler, it
seems to be the PowerPC version, and mostly just maps Altivec names to the
"__builtin_*" functions.


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

I guess we'll have to cross that bridge when we get to it.

-John


On Tue, Dec 8, 2009 at 10:47 AM, Chris Lattner <clattner at apple.com> wrote:

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


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20091208/7e52ff6e/attachment.html>