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

John Thompson john.thompson.jtsoftware at gmail.com
Tue Jan 5 18:33:00 PST 2010

Thanks, Doug.

> Typo "preceeded".

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


>    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

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

>    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
I pulled it for now.

>     pixel is an unsigned short? Weird.

Yeah, totally weird.

I've enclosed an updated patch.

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

More information about the cfe-commits mailing list