[cfe-commits] [PATCH] AltiVec vector support - stage 1

[John Thompson]

Hi, I haven't heard back about this patch regarding a first step towards
AltiVec support.  Is it okay to check-in?

On Tue, Jan 5, 2010 at 9:05 PM, John Thompson <
john.thompson.jtsoftware at gmail.com> wrote:

>  Sorry, I forgot to include the two updated altivec tests, plus update the
> tree before making the patch.  Please disregard the altivec1a.patch and look
> at this one instead.
>
> Thanks.
>
> -John
>
>   On Tue, Jan 5, 2010 at 6:33 PM, John Thompson <
> john.thompson.jtsoftware at gmail.com> wrote:
>
>> Thanks, Doug.
>>
>>
>>> Typo "preceeded".
>>>
>> Fixed.
>>
>>
>>
>>>   I think this is right, but I want to check: are AltiVec vectors more
>>> like GCC's vectors (handled by VectorType) or more like OpenCL's vectors
>>> (handled by ExtVectorType)? OpenCL vectors are mainly GCC's vectors + the
>>> swizzling syntax like "myvec.xy".
>>>
>>>
>>
>> I checked the Altivec standard, and don't see anything like the swizzling
>> syntax, so I think they're more like the GCC vectors.
>>
>> It would be more efficient just to keep the IdentiferInfo * for the
>>> identifiers "vector" and "pixel" in the parser (only when AltiVec is
>>> enabled, of course), then do a pointer comparison rather than a string
>>> comparison.
>>
>>
>> Good idea.  I've fixed this.
>>
>>
>>    +        const Token &nextToken = NextToken();
>>>
>>> Tokens are small; it's best to just copy them, e.g.,
>>>
>>>   Token nextToken = NextToken();
>>>
>>>
>>
>> Got it.
>>
>>
>>>   By changing the current token, we lose track of whether we saw
>>> "vector" or "__vector"; I guess it doesn't really matter. Still, wouldn't it
>>> be easier just to update the DeclSpec at this point?
>>>
>>
>> Yep.
>>
>>
>>
>>>    At some point, we'll need more semantic checking here, e.g., to
>>> ignore "long long" and complain about the deprecation of "long", if I'm to
>>> believe
>>>
>>
>> Yep.  I put in a warning for use of "long", and an error for use of
>> "double".
>>
>>
>>>
>>> http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc03altivec_types.htm
>>>
>>> Or perhaps there's some actual AltiVec specification I could use to help
>>> understand this stuff better?
>>>
>>
>> Here's the one I've been using:
>> http://www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf
>>
>>
>>>    It would probably be better to print with "__vector" and "__pixel",
>>> since those keywords are always available.
>>>
>>
>> Got it.
>>
>>
>>>    This makes it so that AltiVec vectors are completely distinct types
>>> from equivalently-sized vectors (as declared with
>>> __attribute__((vector_size(blah))). If we want to be able to cast between
>>> AltiVec vectors and GCC-style vectors, we'll need to add type-compatibility
>>> logic (for C) and type-conversion logic (for C++). I don't know which way is
>>> correct... how does GCC handle compatibility between the various kinds of
>>> vectors? We'll need to follow its lead.
>>>
>>
>> I took a crack at this in SemaOverload.cpp.
>>
>>
>>>
>>>  Index: lib/Parse/ParseDecl.cpp
>>> ===================================================================
>>> --- lib/Parse/ParseDecl.cpp (revision 91204)
>>> +++ lib/Parse/ParseDecl.cpp (working copy)
>>> @@ -393,6 +393,12 @@
>>>    }
>>>
>>>    if (AllowFunctionDefinitions && D.isFunctionDeclarator()) {
>>> +    // If attributes are present, parse them now.
>>> +    if (Tok.is <http://tok.is/>(tok::kw___attribute)) {
>>> +      SourceLocation Loc;
>>> +      AttributeList *AttrList = ParseGNUAttributes(&Loc);
>>> +      D.AddAttributes(AttrList, Loc);
>>> +    }
>>>
>>> This seems totally unrelated to AltiVec vectors?
>>>
>>
>> Sorry.  Some code from my attribute position fix that hasn't gotten
>> through yet.
>> I pulled it for now.
>>
>>
>>>     pixel is an unsigned short? Weird.
>>>
>>
>> Yeah, totally weird.
>>
>> I've enclosed an updated patch.
>>
>> -John
>>
>>
>
>
>
>  --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>


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