primitive vector types

[Mattias Holm]

On 2009-02-19 21:04:06 +0100, Bill Baxter <wbaxter at gmail.com> said:
> To justify making them primitive types you need to show that they are
> widespread, and that there is some good reason that they cannot be
> implemented in a library.  And even if they can't be implemented in a
> library right now, it could be that fixing that reason is better than
> making new built-in types.   For instance I think there's issues now
> with getting the right stack alignment for structs.  But that's
> something that needs to be fixed generally, not by making new built-in
> types that know how to do alignment right.

Firstly they are widespread. They might be hampered by the fact that 
they have no direct support in many languages however. There are 
reasons that you nowdays have standard vector syntax in GCC. It is a 
bit rough (only support basic operations like elementwise add, div, mul 
et.c.) and does not support permutations. The cross product is only a 
nice to have operator for floats, but it is far from neccisary, 
permutations are more painful though as GCC at the moment force you to 
write CPU-speciffic intrincics for them.

There are firstly the alignment issuse, but there are as other said 
alignment attribute in D as well. More problematic for a library 
implementation of these types is however calling conventions.

Passing a vector into a function is very efficient, they can be passed 
in registers for both in and out values (if the ABI allows, I think PPC 
and x86-64 calling conventions allow for this). The problem with the 
GCC versions however is that due to how the vectors work in it, you 
have to resort to union hacks to get the scalars out of a vector:

union {
	_m128 data;
	struct {
		float x, y, z, w;
	}
}

Unfortunatelly, due to this, in order to make the compiler issue nice 
code, you have to work with the vector type only, and only bring out 
the union when inspecting the scalars in the vector. Which 
unfortunatelly will happen quite often (since the union has an 
ambiguous call by value semantic, should it be passed by one or four 
xmm regs (assuming x86-64 conventions)).

Also, if a vector is a struct you do get the alignment issuse in some 
cases but you may also have different call by value calling conventions 
(with the x86-64 they would in principle be the same, but that is just 
coincidence).

I do agrre that if it could be implemeted a library type, then it 
should, but this doesn't work if you take the fact of calling 
conventions into account.

Also, I am sure that the optimiser could more easily make 
transformations of vector types than on structs that are being passed 
around since the semantics of a primitive type is known by the compiler.


/ Mattias