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

[John Thompson]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20100105/113bad2e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: altivec1b.patch
Type: application/octet-stream
Size: 41593 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20100105/113bad2e/attachment.obj>