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

[John Thompson]

Nudge nudge...

I know I need to do an error message checking test too.  This is just a
start, to avoid too much change at once, and to make sure I'm on the right
track.  Please review it before it gets too stale.

-John

On Fri, Dec 11, 2009 at 8:03 PM, John Thompson <
john.thompson.jtsoftware at gmail.com> wrote:

> Here's a stab a the first stage of adding AltiVec vector support,
> supporting the AltiVec types __vector, vector, __pixel, pixel, and bool.
> I've also enclosed a couple of tests for it for the test/Parser directory.
>
> Some of it might be iffy, but I hope you can help me get it into shape with
> your feedback.
>
> I added a couple of flags to the DeclSpec class to help me know when the
> types are used, TypeAltiVecVector and TypeAltiVecPixel.  The AltiVec
> standard doesn't say much about pixel, other than it is used as "__vector
> __pixel", and that it represents 8 unsigned shorts.  Therefore, instead of
> making a new TST, I made it more like an alias via the TypeAltiVecPixel
> flag.
>
> I also added two corresponding flags to the VectorType class (and the
> getVectorType function).  Currently, these mainly just help with printing,
> but maybe there will be a need to distinguish down the road.  This is kind
> of an iffy part, because there were a couple of places where I don't know if
> the vector involved is an AltiVec vector, and the flags are used in the type
> look up.
>
> Per the previous conversation, I made __vector and __pixel true keywords if
> -faltivec is used, and vector and pixel are context-sensitive keywords.  The
> AltiVec standard also specifies that bool is a keyword in C, so I diddled
> the token flags a bit for that too.
>
> I put the Token patching code in inline functions, so I hope the
> performance impact is not too bad.
> There's probably some holes in the testing, i.e. sizeof.  But, because I'm
> piggy-backing on the existing vectors, I'm hoping most things will still
> just work.
>
> I'm not sure what the next stage should be, the built-in functions?
>
> Thanks.
>
> -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/20091216/12ce9bcb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: altivec1.patch
Type: application/octet-stream
Size: 29468 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20091216/12ce9bcb/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cxx-altivec.cpp
Type: application/octet-stream
Size: 1780 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20091216/12ce9bcb/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: altivec.c
Type: application/octet-stream
Size: 1591 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20091216/12ce9bcb/attachment-0002.obj>