"vector" type, PS3 targets

Clang Frontend
#1

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

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.

Thanks.

-John

ps3triple.patch (1.56 KB)

ps3targets.patch (2.27 KB)

#2

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

#3

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

#4

That appears to be a bug, since gcc accepts the construct; please file.

-Eli