GCC Vector Extensions

GCC Vector Extensions

[Christian Schoenebeck]

Hi!

I just read the GCC Vector Extensions doc [1] and have a few questions.

a) The last code block in that doc [1] uses "builtin" functions? Why should
somebody use those builtin functions when the normal C operations on the new
vector extension types do the same?

b) We wondered [2] what the currently best way is to access single elements of
one vector. Currently the only solution we saw is to use a union trick like:

typedef struct {
        float _1;
        float _2;
        float _3;
        float _4;
} quad_samples;

typedef float v4sf __attribute__ ((vector_size (16)));

typedef union {
        quad_samples s;
        v4sf v;
} quad_sample_t;

Is there a better way to access single elements of a vector?

c) What I'm missing a lot (especially for digital signal processing) are (bit)
shifting operations on the new vector types. Are those planned or already in
work?

[1] http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Vector-Extensions.html#Vector-Extensions
[2] https://bugs.linuxsampler.org/cgi-bin/show_bug.cgi?id=25

CU
Christian

Re: GCC Vector Extensions

[Greg Buchholz]

Christian Schoenebeck wrote:
> b) We wondered [2] what the currently best way is to access single elements of
> one vector. Currently the only solution we saw is to use a union trick

/* I don't know if this qualifies as good, but here's some things
   I've used before  */

#include<stdio.h>
#include<stdlib.h>
#include<string.h>
typedef float v4sf __attribute__ ((vector_size (16)));

int main()
{
    v4sf  a,b,c;
    float *z;

    ((float *)&a)[0] = 1.0;
    ((float *)&a)[1] = 2.0;
    ((float *)&a)[2] = 3.0;
    ((float *)&a)[3] = 4.0;
    
    memcpy((float *)&b,(float[]){0.5,0.6,0.7,0.8},4*sizeof(float));
    
    c = a + b;

    z = (float *)&c;
    
    printf("%f, %f, %f, %f\n", *z, *(z+1), z[2], z[3]);
  
    return 0;
}

Re: GCC Vector Extensions

[Christian Schoenebeck]

Es geschah am Friday, 7. April 2006 22:17 als Greg Buchholz schrieb:
> Christian Schoenebeck wrote:
> > b) We wondered [2] what the currently best way is to access single
> > elements of one vector. Currently the only solution we saw is to use a
> > union trick
>
> /* I don't know if this qualifies as good, but here's some things
>    I've used before  */

Oh, it officially qualified as good! We just made some benchmarks [1] to
compare our old union trick vs. your straight forward type casts and your
solutions were always faster, often even quite a lot. So as we thought, gcc
doesn't like that union thing very much.

Thanks!

CU
Christian

[1] http://sourceforge.net/mailarchive/forum.php?thread_id=10134400&forum_id=12792

Re: GCC Vector Extensions

[Andrew Haley]

Christian Schoenebeck writes:
 > Es geschah am Friday, 7. April 2006 22:17 als Greg Buchholz schrieb:
 > > Christian Schoenebeck wrote:
 > > > b) We wondered [2] what the currently best way is to access single
 > > > elements of one vector. Currently the only solution we saw is to use a
 > > > union trick
 > >
 > > /* I don't know if this qualifies as good, but here's some things
 > >    I've used before  */
 > 
 > Oh, it officially qualified as good! We just made some benchmarks
 > [1] to compare our old union trick vs. your straight forward type
 > casts and your solutions were always faster, often even quite a
 > lot. So as we thought, gcc doesn't like that union thing very much.

It's not legal C, though.  The _mm_load, _mm_set, and _mm_store
operations are provided to do the conversions.

Andrew.

Re: GCC Vector Extensions

[Christian Schoenebeck]

Es geschah am Tuesday, 18. April 2006 12:04 als Andrew Haley schrieb:
> Christian Schoenebeck writes:
>  > Es geschah am Friday, 7. April 2006 22:17 als Greg Buchholz schrieb:
>  > > Christian Schoenebeck wrote:
>  > > > b) We wondered [2] what the currently best way is to access single
>  > > > elements of one vector. Currently the only solution we saw is to use
>  > > > a union trick
>  > >
>  > > /* I don't know if this qualifies as good, but here's some things
>  > >    I've used before  */
>  >
>  > Oh, it officially qualified as good! We just made some benchmarks
>  > [1] to compare our old union trick vs. your straight forward type
>  > casts and your solutions were always faster, often even quite a
>  > lot. So as we thought, gcc doesn't like that union thing very much.
>
> It's not legal C, though.  The _mm_load, _mm_set, and _mm_store
> operations are provided to do the conversions.

Well, those intrinsics would make it hardware dependent though. I thought the
reason for introducing the vector extension was to avoid this. Anyway, I don't
mind if this is legal C or not until it works^TM.

Unfortunately we found a case [1] which did not work at all: a type cast from
float vector to integer vector, like:

    typedef float   v4sf  __attribute__ ((vector_size(16),aligned(16)));
    typedef int     v4i   __attribute__ ((vector_size(sizeof(int)*4)));

    int main() {
        const v4sf v = { 1.2f ,2.2f ,3.3f, 4.4f };
        const v4i vRes = (v4i) v;
    }

The resulting integer vector vRes would simply contain crap.
Is this a bug, not implemented yet or even intentional?

CU
Christian

[1] http://sourceforge.net/mailarchive/forum.php?thread_id=10191980&forum_id=12792

Re: GCC Vector Extensions

[Andrew Haley]

Christian Schoenebeck writes:
 > Es geschah am Tuesday, 18. April 2006 12:04 als Andrew Haley schrieb:
 > > Christian Schoenebeck writes:
 > >  > Es geschah am Friday, 7. April 2006 22:17 als Greg Buchholz schrieb:
 > >  > > Christian Schoenebeck wrote:
 > >  > > > b) We wondered [2] what the currently best way is to access single
 > >  > > > elements of one vector. Currently the only solution we saw is to use
 > >  > > > a union trick
 > >  > >
 > >  > > /* I don't know if this qualifies as good, but here's some things
 > >  > >    I've used before  */
 > >  >
 > >  > Oh, it officially qualified as good! We just made some benchmarks
 > >  > [1] to compare our old union trick vs. your straight forward type
 > >  > casts and your solutions were always faster, often even quite a
 > >  > lot. So as we thought, gcc doesn't like that union thing very much.
 > >
 > > It's not legal C, though.  The _mm_load, _mm_set, and _mm_store
 > > operations are provided to do the conversions.
 > 
 > Well, those intrinsics would make it hardware dependent though. I
 > thought the reason for introducing the vector extension was to
 > avoid this. Anyway, I don't mind if this is legal C or not until it
 > works^TM.
 > 
 > Unfortunately we found a case [1] which did not work at all: a type cast from
 > float vector to integer vector, like:
 > 
 >     typedef float   v4sf  __attribute__ ((vector_size(16),aligned(16)));
 >     typedef int     v4i   __attribute__ ((vector_size(sizeof(int)*4)));
 > 
 >     int main() {
 >         const v4sf v = { 1.2f ,2.2f ,3.3f, 4.4f };
 >         const v4i vRes = (v4i) v;
 >     }
 > 
 > The resulting integer vector vRes would simply contain crap.
 > Is this a bug, not implemented yet or even intentional?

I don't know, because there's not enough information here.  Can you
produce a runnable test case?

Andrew.

Re: GCC Vector Extensions

[Christian Schoenebeck]

[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

Es geschah am Wednesday, 19. April 2006 10:30 als Andrew Haley schrieb:
>  > Unfortunately we found a case [1] which did not work at all: a type cast
>  > from float vector to integer vector, like:
>  >
>  >     typedef float   v4sf  __attribute__ ((vector_size(16),aligned(16)));
>  >     typedef int     v4i   __attribute__ ((vector_size(sizeof(int)*4)));
>  >
>  >     int main() {
>  >         const v4sf v = { 1.2f ,2.2f ,3.3f, 4.4f };
>  >         const v4i vRes = (v4i) v;
>  >     }
>  >
>  > The resulting integer vector vRes would simply contain crap.
>  > Is this a bug, not implemented yet or even intentional?
>
> I don't know, because there's not enough information here.  Can you
> produce a runnable test case?

Ok, attached you find one with output. When you run it, it should actually 
show this:

	v4sf v = { 1.200000, 2.200000, 3.300000, 4.400000 }
	v4i vRes = { 1, 2, 3, 4 }

but instead I get this:

	v4sf v = { 1.200000, 2.200000, 3.300000, 4.400000 }
	v4i vRes = { 1067030938, 1074580685, 1079194419, 1082969293 }

I can hardly believe this is intentional, is it?

CU
Christian

[-- Attachment #2: foo.cpp --]
[-- Type: text/x-c++src, Size: 470 bytes --]

#include <stdio.h>

typedef float	v4sf  __attribute__ ((vector_size(16),aligned(16)));
typedef int	v4i   __attribute__ ((vector_size(sizeof(int)*4)));

int main() {
    const v4sf v = { 1.2f ,2.2f ,3.3f, 4.4f };
    printf("v4sf v = { %f, %f, %f, %f }\n", ((float*)&v)[0],((float*)&v)[1],((float*)&v)[2],((float*)&v)[3]);
    const v4i vRes = (v4i) v;
    printf("v4i vRes = { %d, %d, %d, %d }\n", ((int*)&vRes)[0],((int*)&vRes)[1],((int*)&vRes)[2],((int*)&vRes)[3]);
}

Re: GCC Vector Extensions

[John Love-Jensen]

Hi Christian,

I believe the...
  const v4i vRes = (v4i) v;
...will do a memcpy, not a float to int conversion.

If you change it to...
  const v4i vRes = v;
... you get error: cannot convert 'const float __vector__' to 'const int
__vector__' in initialization

I think your big hammer cast is hiding the problem.  Your %d output is the
int32 values of the bit patterns of the float32 values.

HTH,
--Eljay

Re: GCC Vector Extensions

[Andrew Haley]

Christian Schoenebeck writes:
 > Es geschah am Wednesday, 19. April 2006 10:30 als Andrew Haley schrieb:
 > >  > Unfortunately we found a case [1] which did not work at all: a type cast
 > >  > from float vector to integer vector, like:
 > >  >
 > >  >     typedef float   v4sf  __attribute__ ((vector_size(16),aligned(16)));
 > >  >     typedef int     v4i   __attribute__ ((vector_size(sizeof(int)*4)));
 > >  >
 > >  >     int main() {
 > >  >         const v4sf v = { 1.2f ,2.2f ,3.3f, 4.4f };
 > >  >         const v4i vRes = (v4i) v;
 > >  >     }
 > >  >
 > >  > The resulting integer vector vRes would simply contain crap.
 > >  > Is this a bug, not implemented yet or even intentional?
 > >
 > > I don't know, because there's not enough information here.  Can you
 > > produce a runnable test case?
 > 
 > Ok, attached you find one with output. When you run it, it should actually 
 > show this:
 > 
 > 	v4sf v = { 1.200000, 2.200000, 3.300000, 4.400000 }
 > 	v4i vRes = { 1, 2, 3, 4 }
 > 
 > but instead I get this:
 > 
 > 	v4sf v = { 1.200000, 2.200000, 3.300000, 4.400000 }
 > 	v4i vRes = { 1067030938, 1074580685, 1079194419, 1082969293 }
 > 
 > I can hardly believe this is intentional, is it?

I've started a conversation on the gcc discuss list, and we think it's
probably a bug.  There's a thread at
http://gcc.gnu.org/ml/gcc/2006-04/msg00349.html.

Andrew.

Re: [Linuxsampler-devel] Re: GCC Vector Extensions

[Harri Järvi]

On Wed, Apr 19, 2006 at 14:40:01 +0200, Christian Schoenebeck wrote:
> int main() {
>     const v4sf v = { 1.2f ,2.2f ,3.3f, 4.4f };
>     printf("v4sf v = { %f, %f, %f, %f }\n", ((float*)&v)[0],((float*)&v)[1],((float*)&v)[2],((float*)&v)[3]);
>     const v4i vRes = (v4i) v;
>     printf("v4i vRes = { %d, %d, %d, %d }\n", ((int*)&vRes)[0],((int*)&vRes)[1],((int*)&vRes)[2],((int*)&vRes)[3]);
> }

Shouldn't one use c++-style casts instead. static_cast<type>() is the 
one I think would be the one to use here. C-style casts are ambigous and 
most of the time its difficult or impossible to know what they should 
do.

This is the case because there is only one notation for all different 
type casts in C. In C++ you can use different type cast for different 
things.

See http://www.cplusplus.com/doc/tutorial/typecasting.html
for all 4 type casts in C++.

-Harri

Re: [Linuxsampler-devel] Re: GCC Vector Extensions

[Brian Budge]

Seeing as how this is a gcc vector extension, why not add a special
casting mechanism?  The method described by Harri makes some sense,
because you could use static_cast to do an element by element cast and
reinterpret_cast to move between types via bitcopies.

Of course, since I believe this should be useful in C, templates are
not a viable method (and hence static_cast and reinterpret_cast) for
the C language.

A similar mechanism should be possible in C, although it may need to
end up being more verbose (ie. static_cast_v4sf_v4i(v4sf),
bit_cast_v4sf_v4i(v4sf) ).

  Brian

On 4/19/06, Harri Järvi <harri.jarvi@ajatus.org> wrote:
> On Wed, Apr 19, 2006 at 14:40:01 +0200, Christian Schoenebeck wrote:
> > int main() {
> >     const v4sf v = { 1.2f ,2.2f ,3.3f, 4.4f };
> >     printf("v4sf v = { %f, %f, %f, %f }\n", ((float*)&v)[0],((float*)&v)[1],((float*)&v)[2],((float*)&v)[3]);
> >     const v4i vRes = (v4i) v;
> >     printf("v4i vRes = { %d, %d, %d, %d }\n", ((int*)&vRes)[0],((int*)&vRes)[1],((int*)&vRes)[2],((int*)&vRes)[3]);
> > }
>
> Shouldn't one use c++-style casts instead. static_cast<type>() is the
> one I think would be the one to use here. C-style casts are ambigous and
> most of the time its difficult or impossible to know what they should
> do.
>
> This is the case because there is only one notation for all different
> type casts in C. In C++ you can use different type cast for different
> things.
>
> See http://www.cplusplus.com/doc/tutorial/typecasting.html
> for all 4 type casts in C++.
>
> -Harri
>

Re: GCC Vector Extensions

[Andrew Haley]

OK, I got it now.

The full spec is at

http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc03altivec_types.htm

and the relevant passage is

"Vector types can be cast to other vector types. The cast does not 
perform a conversion: it preserves the 128-bit pattern, but not 
necessarily the value. A cast between a vector type and a scalar type is 
not allowed."

Andrew.

Re: GCC Vector Extensions

[Christian Schoenebeck]

Es geschah am Wednesday, 19. April 2006 17:20 als Andrew Haley schrieb:
> OK, I got it now.
>
> The full spec is at
>
> http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/co
>m.ibm.vacpp6m.doc/language/ref/clrc03altivec_types.htm

Well, this is a different compiler and the docs are just about this compiler, 
not a regular language specification.

> and the relevant passage is
>
> "Vector types can be cast to other vector types. The cast does not
> perform a conversion: it preserves the 128-bit pattern, but not
> necessarily the value. A cast between a vector type and a scalar type is
> not allowed."

The bitstream theory is correct, I just checked this.

Es geschah am Wednesday, 19. April 2006 14:58 als Robert Dewar schrieb:
> Andrew Haley wrote:
> > Converting a vector of floats (via a cast) to a vector of ints of the
> > same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
> > converted.  This is different from a cast from scalar float to int,
> > where a conversion is performed.a
>
> Yes, that's the way C is defined
>
> From what I can see of the source, this is deliberate.
>
> I should hope so :-)
> >   But is this behaviour documented anywhere?
> In any book on C, or of course in the C standard.

Uh? Since when are vector types part of the C standard? I hardly believe that, 
since other compilers use a different way to declare vector types for 
example. If I'm wrong, could you point us to the relevant passage in the 
specification?

Es geschah am Wednesday, 19. April 2006 15:41 als Ian Lance Taylor schrieb:
> Converting a vector of floats (via a cast) to a vector of ints of the
> same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
> converted.  This is different from a cast from scalar float to int,
> where a conversion is performed.
> In general there is a conflict within gcc between treating vectors as
> unitary types and treating them as collections.  In this case we are
> treating them as unary.  However, I think that by analogy to the way
> we handle arithmetic, and given the existence of instructions like
> cvtdq2ps in real vector processors, I think it would be better to
> handle converstions on an element by element basis.
>
> That is, I think this is a bug.

Exactly, logically it should be treated on element basis by default. I'll dig 
if I can find something about this in the C specs, but I doubt it. ATM I 
assume this to be a wrong implementation of the cast.

Es geschah am Wednesday, 19. April 2006 17:16 als Paolo Bonzini schrieb:
> > Secondly, can we fix it?
>
> We can do anything we want. Or we can do nothing -- it depends on the point
> of view. :-) While looking at PR10735, one or two years ago I set to
> implement some rules resembling the ones outlined by Ian, only to find that
> I would break the Altivec tests in a horrible way.

That's an irrational argument to me, defining a high level language based on 
certain low level circumstances of one, single architecture.

>  For sure, we cannot fix the Altivec spec. Consider that Altivec does not
> even have an instruction for a value-preserving V4SF->V4SI or V4SI->V4SF
> conversion.

Yeah, but also consider that old PPCs did not even have an instruction for
int->float conversion. Is that a reason for defining a scalar int->float cast 
as bitstream copy? Certainly not.

CU
Christian

Re: GCC Vector Extensions

[Andrew Haley]

Christian Schoenebeck writes:
 > Es geschah am Wednesday, 19. April 2006 17:20 als Andrew Haley schrieb:
 > > OK, I got it now.
 > >
 > > The full spec is at
 > >
 > > http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc03altivec_types.htm
 > 
 > Well, this is a different compiler and the docs are just about this
 > compiler, not a regular language specification.

Sure, but it's the base we used for gcc, and it's what current users
expect.

 > Yeah, but also consider that old PPCs did not even have an
 > instruction for int->float conversion. Is that a reason for
 > defining a scalar int->float cast as bitstream copy? Certainly not.

Too late: it's the specification.  See 

"2.4.6 Type Casting

"... None of the casts performs a conversion; the bit pattern of the
result is the same as the bit pattern of the argument that is cast."

The full spec is at http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/30B3520C93F437AB87257060006FFE5E/$file/SPU_language_extensions_2.1.pdf

Now, you might think that we need a different specification, and lots
of people would agree with you!  But it's not a bug in the gcc
implementation.

Andrew.