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

[John Thompson]

Sorry, I forgot to attach the updated patch.

On Wed, Jan 20, 2010 at 4:11 PM, John Thompson <
john.thompson.jtsoftware at gmail.com> wrote:

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


-- 
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/ef46b2bd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: altivec1c.patch
Type: application/octet-stream
Size: 42247 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20100120/ef46b2bd/attachment.obj>