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

[John Thompson]

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