[cfe-dev] "vector" type, PS3 targets

John Thompson john.thompson.jtsoftware at gmail.com
Wed Nov 25 11:59:06 PST 2009


Thanks, Doug.

I also found this page, PowerPC-specific:
http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/PowerPC-AltiVec-Built_002din-Functions.html
In the PS3 gcc, "vector" appears to be built-in.

Using the info from the page you pointed me to, I've been experimenting a
little to see what Clang seems to understand.  Apparently I can do something
like this:

  __attribute__((vector_size(16))) unsigned char MyVectorVariable;

And I can do:

  typedef __attribute__((vector_size(16))) unsigned char MyVectorTypeUC;
But if I try to simulate the "vector" type with a typedef, I can't do:

  typedef __attribute__((vector_size(16))) vector;
  vectest.cpp:19:3: error: declaration does not declare anything
    typedef __attribute__((vector_size(16))) vector;
Also, I can do:

  MyVectorTypeUC vec_add(MyVectorTypeUC, MyVectorTypeUC);

and

  void f1(__attribute__((vector_size(16))) unsigned char,
__attribute__((vector_size(16))) unsigned char);

But I can't use the raw notation in a return type:

  __attribute__((vector_size(16))) unsigned char f();
   vectest.cpp:9:16: error: unsupported type 'unsigned char ()' for
vector_size attribute,  please use on typedef
  __attribute__((vector_size(16))) unsigned char f();

I guess the attribute is trying to associate with the function declaration.

I looked at:

  #define vector __attribute__((vector_size(16)))

But then that would conflict with the library's vector class, as well as
have problems with function return types.

BTW, how would a built-in "vector" type not conflict with the vector class?
Is it the types following it that allow the compiler to differentiate?
(I.e. in seeing "vector int", the "int" part tells that compiler the vector
keyword is used?)

So, down to the question I want to ask, would it be reasonable for me to
implement a built-in vector type in Clang, perhaps enabled by the -faltivec
option?  Or is there a correct way to otherwise do it with existing
features?

It looks like something needed in the PS3/PowerPC world.

-John

On Thu, Nov 19, 2009 at 9:09 AM, Douglas Gregor <dgregor at apple.com> wrote:

>
> On Nov 18, 2009, at 3:41 PM, John Thompson wrote:
>
> Hi,
>>
>> I thought I'd to some preliminary work to see what issues I'd run into
>> trying to compile some sources intented for the PS3 PPU target.  The PS3
>> devkit includes a gcc-based compiler, so I'm thinking that would make it a
>> bit easier.
>>
>> Although there is a -faltivec option, it appears that there is no support
>> yet for the "vector" type (or is it really "__vector", or perhaps a built-in
>> alias?).
>>
>
> There's a little bit of information about a "__vector" in the "PowerPC Type
> Attributes" section of the GCC manual, here:
>
>
> http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Type-Attributes.html#Type-Attributes
>
>
> I don't know much about this, so I was wondering if someone out there could
>> say something about it with respect to plans for it in clang.
>>
>
> Clang currently supports two kinds of vector types, the GNU vector
> attribute (e.g., "int __attribute__((vector_size(number-of-bytes)))") and
> Clang's own OpenCL-inspired extended vector attribute (e.g., "int
> __attribute__((ext_vector_type(number-of-elements)))"). The Altivec
> vector/__vector probably matches one of those.
>
>
> I suppose that in addition to the vector type, this would also involve all
>> the "__builtin_vec-*" functions, but not having the vector type used in the
>> altivec.h include file was the first thing I ran into.
>> I've enclosed some initial work for the targets, in ps3targets.patch.
>>  This depends on changes to the Triple class in ps3triple.patch, which I've
>> submitted seperately to the llvmdev list.  The gcc-based compiler in the PS3
>> devkit uses the the "ppu-uknown-lv2" and "spu-unknown-lv2" triples, so these
>> changes do the same.  I don't know why there isn't a "ps3" in there
>> somewhere, but it probably should be the same in both compilers.
>>
>
> +    // FIXME:  Does this belong in PPCTargetInfo?
> +    if (Opts.AltiVec) {
> +      Define(Defs, "__VEC__", "1");
> +      Define(Defs, "__ALTIVEC__", "1");
> +    }
>
> GCC defines both of these when compiling for PPC, so they should go into
> PPCTargetInfo. I'm seeing the following definitions:
>
> #define __VEC__ 10206
> #define __ALTIVEC__ 1
>
> Otherwise, the triple and target changes look good!
>
>  - Doug
>



-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20091125/642beb87/attachment.html>


More information about the cfe-dev mailing list