This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Single Element Vectors
- From: Kumar Gala <kumar dot gala at motorola dot com>
- To: Aldy Hernandez <aldyh at redhat dot com>
- Cc: Richard Henderson <rth at redhat dot com>, Nick Clifton <nickc at redhat dot com>, <gcc at gcc dot gnu dot org>
- Date: Fri, 13 Sep 2002 00:17:05 -0500
- Subject: Re: Single Element Vectors
The problem is that they have an __ev64_u64__ type for initialization
purposes. That is, they want the type to be a vector, but want to
initialize it from a 64-bit long.
This is somewhat, true. I think of it more as a single element array,
just like the fact that C does not require that I have array of element
size 2 or great (because 1 is just the same as a scalar)
I really dont care if this works (if it does according to C
initialization rules, great, if not no problem):
__ev64_u64__ x = 23423ull;
However, I do want this to work:
__ev64_u64__ x = { 243ull };
However, when the __ev64_u64__ is
used, they want it to have the vector's ABIness when it comes to
argument passing, not long long argument passing rules.
This is true, I wanted to provide the user with the ability to have a
set of types that they could build type safe code on top of the
compiler support and expect the right thing to happen w/respect to the
ABI. In this way the could build AltiVec PIM style support with
overloaded (C++) functions if they wanted to. Without the compiler
making distinguishing between __ev64_u64__ and long long this would not
be possible (and have the ABI followed).
What I have suggested is having macros used for initialization, as so:
#define VECTOR_INT_FROM_LONG_LONG(x) ((vector int)x)
vector int foo = VECTOR_INT_FROM_LONG_LONG(65LL);
While this would solve the initialization problem, it does not solve
the problem of having a data type that the user can use.
Nick also has a patch (that I'm not too fond off, but I *could*
consider if there's no other way), that looks at the typedef name
("__ev64_u64__" in this case) to determine where arguments should go.
I did NOT think that Nick's patch looked at the typedef name, but
introduced a V1DImode, and used that to handle these cases, but I could
have missed something in it.
As I mentioned earlier, vectors of one element seem natural to me
writing C code. C allows me to have arrays of one element, C++ allows
me to have STL vectors of one element, I am not sure while GCC will not
allow me to have hardware vectors w/one element.
- kumar