Sorry to start a new thread on this, but I didn't want it to get lost in
the middle of the previous comments.  I have the start of a working
implementation in gdc giving access to the __builtin_ia32_* functions.
The way I did it so far manages to compile down to very tight SSE code.
 That's the good part.

The bad part is that there are a couple of limitations that engender slightly ugly code at the moment.

Issue 1:

In order for the compiler to actually recognize the builtins when you call them, I had to define a set of custom types that represent gcc's types with the vector_size attribute that get passed into the builtins.

I couldn't use float[4] for V4SF as I (and Iaian) had hoped, as I can't set the alignment, and it automatically generates calls to _d_array_init and _d_array_copy and such, rather than instead just staying in SSE registers.  Let's just say the code was very non-optimal.

Instead, I create a struct declaration in gcc.builtins for all of the types expected by those builtins, and I name them to match what they would nominally contain: __v4sf would have 4 floats, __v32qi would have 32 bytes, __v2df would have 2 doubles, and so forth.  Each struct has 16-byte alignment and the correct size.  But here's the rub: they have no fields in them.  I tried my darndest to add VarDeclarations to them, but the fact that the actual gcc tree type wasn't a struct, it would just ICE the compiler when instantiating any of those structs.

I'd like to fix this, so that you can literally access the contents of the struct like it had a float[4], or a double[2], or a byte[32], or whatever it should actually have; or instead it should give you an overloaded [] operator for direct indexing.

Issue 2:

The builtin structs I generate are *not* recognized by the frontend as having support for +, -, *, /, etc like the gcc vector_size types automatically do in C and C++.  I might be able to add those and have them contain code to drop into the builtins.  For now, you *must* use the builtin functions to perform operations on these types.  I'm obviously aiming to use the builtin functions, myself (for now).

Quick example:

///// File VectorsMain.d /////

import gcc.builtins;
import mmintrins;
import std.stdio;

void main()
{
    __v4sf bv1;
    setvelem(bv1, 0, 1.0f);
    setvelem(bv1, 1, 2.0f);
    setvelem(bv1, 2, 3.0f);
    setvelem(bv1, 3, 0.0f);

    __v4sf bv2;
    setvelem(bv2, 0, 1.0f);
    setvelem(bv2, 1, 1.0f);
    setvelem(bv2, 2, 1.0f);
    setvelem(bv2, 3, 0.0f);

    __v4sf bv3 = _mm_add_ps(bv1, bv2);

    std.stdio.writefln("Result: (%s, %s, %s, %s)",
                       velem!float(bv3, 0),
                       velem!float(bv3, 1),
                       velem!float(bv3, 2),
                       velem!float(bv3, 3));
}

///// File mmintrins.d /////

module mmintrins;

import gcc.builtins;


T velem(T, VT)(VT vector, uint elem)
{
    return (cast(T*) &vector)[elem];
}

void setvelem(T, VT)(ref VT vector, uint elem, T value)
{
    (cast(T*) &vector)[elem] = value;
}


//pragma(set_attribute, _mm_add_ps, always_inline, artificial);
T _mm_add_ps(T)(const(T) v1, const(T) v2)
{
    return __builtin_ia32_addps(v1, v2);
}

///// End example /////

Note a few things: I made _mm_add_ps templated on vector type (I'll constrain it eventually to appropriate types), and this solves a couple of problems: cross-module inlining works as the other module gets the whole definition, and you can technically addps types other than v4sf.

Note the velem and setvelem methods are just to add a pretty face on the
fact that the data of the struct is hidden, with no fields to access it.
 More checks are needed (at least in debug mode), and there will be some
other handy things like _mm_set1_ps and _mm_set_ps to make rapid setup
of vectors easier.  I'll admit that this part is a bit ugly, but it
works, and it generates excellent code.  I compared the actual assembly
generated to my own C++ code with the same intrinsics, and so far the D
side is keeping up.

Please don't collectively throw up when you see this...fast vector ops are kindof a big deal for me, so be gentle. =)  What do you all think?

-Mike

== Quote from Mike Farnsworth (mike.farnsworth@gmail.com)'s article
> Sorry to start a new thread on this, but I didn't want it to get lost in
> the middle of the previous comments.  I have the start of a working
> implementation in gdc giving access to the __builtin_ia32_* functions.
> The way I did it so far manages to compile down to very tight SSE code.
>  That's the good part.
> The bad part is that there are a couple of limitations that engender
> slightly ugly code at the moment.
> Issue 1:
> In order for the compiler to actually recognize the builtins when you
> call them, I had to define a set of custom types that represent gcc's
> types with the vector_size attribute that get passed into the builtins.
> I couldn't use float[4] for V4SF as I (and Iaian) had hoped, as I can't
> set the alignment, and it automatically generates calls to _d_array_init
> and _d_array_copy and such, rather than instead just staying in SSE
> registers.  Let's just say the code was very non-optimal.

I didn't hope for anything, I'm not the crazy one using them. =)

> Instead, I create a struct declaration in gcc.builtins for all of the
> types expected by those builtins, and I name them to match what they
> would nominally contain: __v4sf would have 4 floats, __v32qi would have
> 32 bytes, __v2df would have 2 doubles, and so forth.  Each struct has
> 16-byte alignment and the correct size.  But here's the rub: they have
> no fields in them.  I tried my darndest to add VarDeclarations to them,
> but the fact that the actual gcc tree type wasn't a struct, it would
> just ICE the compiler when instantiating any of those structs.
> I'd like to fix this, so that you can literally access the contents of
> the struct like it had a float[4], or a double[2], or a byte[32], or
> whatever it should actually have; or instead it should give you an
> overloaded [] operator for direct indexing.
> Issue 2:
> The builtin structs I generate are *not* recognized by the frontend as
> having support for +, -, *, /, etc like the gcc vector_size types
> automatically do in C and C++.  I might be able to add those and have
> them contain code to drop into the builtins.  For now, you *must* use
> the builtin functions to perform operations on these types.  I'm
> obviously aiming to use the builtin functions, myself (for now).

Actually, more I think about it, the more I feel a user-defined union would be better to scale the shortcomings of gcc attribute support in gdc. And trying to use whatever builtins gcc has to offer won't get you anywhere far anytime soon.

There's one or two ICEs when using arithmetic operations (+,-,/,*,=) for typedef'd types with vector attributes assigned to them. This has mostly been fixed in my local tree (with hopefully kind error message for invalid ops too), which will be pushed soon after the next dmd release merge.

> Quick example:
> ///// File VectorsMain.d /////
> import gcc.builtins;
> import mmintrins;
> import std.stdio;
> void main()
> {
>     __v4sf bv1;
>     setvelem(bv1, 0, 1.0f);
>     setvelem(bv1, 1, 2.0f);
>     setvelem(bv1, 2, 3.0f);
>     setvelem(bv1, 3, 0.0f);
>     __v4sf bv2;
>     setvelem(bv2, 0, 1.0f);
>     setvelem(bv2, 1, 1.0f);
>     setvelem(bv2, 2, 1.0f);
>     setvelem(bv2, 3, 0.0f);
>     __v4sf bv3 = _mm_add_ps(bv1, bv2);
>     std.stdio.writefln("Result: (%s, %s, %s, %s)",
>                        velem!float(bv3, 0),
>                        velem!float(bv3, 1),
>                        velem!float(bv3, 2),
>                        velem!float(bv3, 3));
> }
> ///// File mmintrins.d /////
> module mmintrins;
> import gcc.builtins;
> T velem(T, VT)(VT vector, uint elem)
> {
>     return (cast(T*) &vector)[elem];
> }
> void setvelem(T, VT)(ref VT vector, uint elem, T value)
> {
>     (cast(T*) &vector)[elem] = value;
> }
> //pragma(set_attribute, _mm_add_ps, always_inline, artificial);
> T _mm_add_ps(T)(const(T) v1, const(T) v2)
> {
>     return __builtin_ia32_addps(v1, v2);
> }
> ///// End example /////
> Note a few things: I made _mm_add_ps templated on vector type (I'll
> constrain it eventually to appropriate types), and this solves a couple
> of problems: cross-module inlining works as the other module gets the
> whole definition, and you can technically addps types other than v4sf.
> Note the velem and setvelem methods are just to add a pretty face on the
> fact that the data of the struct is hidden, with no fields to access it.
>  More checks are needed (at least in debug mode), and there will be some
> other handy things like _mm_set1_ps and _mm_set_ps to make rapid setup
> of vectors easier.  I'll admit that this part is a bit ugly, but it
> works, and it generates excellent code.  I compared the actual assembly
> generated to my own C++ code with the same intrinsics, and so far the D
> side is keeping up.
> Please don't collectively throw up when you see this...fast vector ops
> are kindof a big deal for me, so be gentle. =)  What do you all think?
> -Mike

I think I'm gonna throw up... :~)

Iain Buclaw Wrote:

> == Quote from Mike Farnsworth (mike.farnsworth@gmail.com)'s article
> > Sorry to start a new thread on this, but I didn't want it to get lost in
> > the middle of the previous comments.  I have the start of a working
> > implementation in gdc giving access to the __builtin_ia32_* functions.
> > The way I did it so far manages to compile down to very tight SSE code.
> >  That's the good part.
> > The bad part is that there are a couple of limitations that engender
> > slightly ugly code at the moment.
> > Issue 1:
> > In order for the compiler to actually recognize the builtins when you
> > call them, I had to define a set of custom types that represent gcc's
> > types with the vector_size attribute that get passed into the builtins.
> > I couldn't use float[4] for V4SF as I (and Iaian) had hoped, as I can't
> > set the alignment, and it automatically generates calls to _d_array_init
> > and _d_array_copy and such, rather than instead just staying in SSE
> > registers.  Let's just say the code was very non-optimal.
> 
> I didn't hope for anything, I'm not the crazy one using them. =)
> 
> > Instead, I create a struct declaration in gcc.builtins for all of the
> > types expected by those builtins, and I name them to match what they
> > would nominally contain: __v4sf would have 4 floats, __v32qi would have
> > 32 bytes, __v2df would have 2 doubles, and so forth.  Each struct has
> > 16-byte alignment and the correct size.  But here's the rub: they have
> > no fields in them.  I tried my darndest to add VarDeclarations to them,
> > but the fact that the actual gcc tree type wasn't a struct, it would
> > just ICE the compiler when instantiating any of those structs.
> > I'd like to fix this, so that you can literally access the contents of
> > the struct like it had a float[4], or a double[2], or a byte[32], or
> > whatever it should actually have; or instead it should give you an
> > overloaded [] operator for direct indexing.
> > Issue 2:
> > The builtin structs I generate are *not* recognized by the frontend as
> > having support for +, -, *, /, etc like the gcc vector_size types
> > automatically do in C and C++.  I might be able to add those and have
> > them contain code to drop into the builtins.  For now, you *must* use
> > the builtin functions to perform operations on these types.  I'm
> > obviously aiming to use the builtin functions, myself (for now).
> 
> Actually, more I think about it, the more I feel a user-defined union would be better to scale the shortcomings of gcc attribute support in gdc. And trying to use whatever builtins gcc has to offer won't get you anywhere far anytime soon.
> 
> There's one or two ICEs when using arithmetic operations (+,-,/,*,=) for typedef'd types with vector attributes assigned to them. This has mostly been fixed in my local tree (with hopefully kind error message for invalid ops too), which will be pushed soon after the next dmd release merge.

I tried to use the typedef'd types, but even with simple ops it gave me all sorts of weird compile errors as soon as I tried to pass them to the intrinsics.  E.g. I can get the +,-,*,/,... operators to work but not the builtin functions, or else with my builtin structs I can get the builtin functions to work, but not the +,-,*,/,... operators to work.  I'm hoping at some point I can get the best of both worlds, but I still feel pretty lost in all the gdc code (although I'm slowly learning).

> > Quick example:
> > ///// File VectorsMain.d /////
> > import gcc.builtins;
> > import mmintrins;
> > import std.stdio;
> > void main()
> > {
> >     __v4sf bv1;
> >     setvelem(bv1, 0, 1.0f);
> >     setvelem(bv1, 1, 2.0f);
> >     setvelem(bv1, 2, 3.0f);
> >     setvelem(bv1, 3, 0.0f);
> >     __v4sf bv2;
> >     setvelem(bv2, 0, 1.0f);
> >     setvelem(bv2, 1, 1.0f);
> >     setvelem(bv2, 2, 1.0f);
> >     setvelem(bv2, 3, 0.0f);
> >     __v4sf bv3 = _mm_add_ps(bv1, bv2);
> >     std.stdio.writefln("Result: (%s, %s, %s, %s)",
> >                        velem!float(bv3, 0),
> >                        velem!float(bv3, 1),
> >                        velem!float(bv3, 2),
> >                        velem!float(bv3, 3));
> > }
> > ///// File mmintrins.d /////
> > module mmintrins;
> > import gcc.builtins;
> > T velem(T, VT)(VT vector, uint elem)
> > {
> >     return (cast(T*) &vector)[elem];
> > }
> > void setvelem(T, VT)(ref VT vector, uint elem, T value)
> > {
> >     (cast(T*) &vector)[elem] = value;
> > }
> > //pragma(set_attribute, _mm_add_ps, always_inline, artificial);
> > T _mm_add_ps(T)(const(T) v1, const(T) v2)
> > {
> >     return __builtin_ia32_addps(v1, v2);
> > }
> > ///// End example /////
> > Note a few things: I made _mm_add_ps templated on vector type (I'll
> > constrain it eventually to appropriate types), and this solves a couple
> > of problems: cross-module inlining works as the other module gets the
> > whole definition, and you can technically addps types other than v4sf.
> > Note the velem and setvelem methods are just to add a pretty face on the
> > fact that the data of the struct is hidden, with no fields to access it.
> >  More checks are needed (at least in debug mode), and there will be some
> > other handy things like _mm_set1_ps and _mm_set_ps to make rapid setup
> > of vectors easier.  I'll admit that this part is a bit ugly, but it
> > works, and it generates excellent code.  I compared the actual assembly
> > generated to my own C++ code with the same intrinsics, and so far the D
> > side is keeping up.
> > Please don't collectively throw up when you see this...fast vector ops
> > are kindof a big deal for me, so be gentle. =)  What do you all think?
> > -Mike
> 
> I think I'm gonna throw up... :~)

Well, keep in mind that I still have a few things to do in the near term that should help:

1) Add at minimum an overloaded [] op to allow direct indexing into the vector structs, which should make the velem/setvelem crap extraneous.

2) Add a bunch more intrinsics wrappers that follow the Intel standard, so the utility of this goes up.

3) Add some example wrapper structs that define all of the relevant operators, dot/cross products, etc.  These will (at least for typical usage) hide all of the ugliness and hopefully will compile down to very good code, while still being proper D types that are easy to understand how to use.

Hopefully then nobody will want to throw up anymore.

-Mike