SIMD support...

[Walter Bright]

On 1/6/2012 1:32 PM, Manu wrote:
> On 6 January 2012 22:36, Walter Bright <newshound2 at digitalmars.com
> <mailto:newshound2 at digitalmars.com>> wrote:
>
>             To me, the advantage of making the SIMD types typed are:
>
>             1. the language does typechecking, for example, trying to add a
>         vector of 4
>             floats to 16 bytes would be (and should be) an error.
>
>
>         The language WILL do that checking as soon as we create the strongly typed
>         libraries. And people will use those libraries, they'll never touch the
>         primitive type.
>
>
>     I'm not so sure this will work out satisfactorily.
>
>
> How so, can you support this theory?

For one thing, the compiler has a very hard time optimizing library implemented 
types. It's why int, float, etc., are native types. We've come a long way with 
library types, but there are limits.

>
>             2. Some of the SIMD operations do map nicely onto the operators, so one
>             could write:
>
>                a = b + c + -d;
>
>
>         This is not even true, as you said yourself in a previous post.
>         SIMD int ops may wrap, or saturate... which is it?
>
>
>     It would only be for those ops that actually do map onto the D operators.
>     (This is already done by the library implementation of the array arithmetic
>     operations.) The saturated int ops would not be usable this way.
>
>
> But why are you against adding this stuff in the library? It's contrary to the
> general sentiment around here where people like putting stuff in libraries where
> possible. It's less committing, and allows alternative implementations if desired.
>
>         Don't try and express this at the language level. Let the libraries do
>         it, and
>         if they fail, or are revealed to be poorly defined, they can be
>         updated/changed.
>
>
>     Doing it as a library type pretty much prevents certain optimizations, for
>     example, the fused operations, from being expressed using infix operators.
>
>
> You're talking about MADD? I was going to make a separate suggestion regarding
> that actually.
> Multiply-add is a common concept, often available to FPU's aswell (and no way to
> express it)... I was going to suggest an opMultiplyAdd() operator, which you
> could have the language call if it detects a conforming arrangement of * and +
> operators on a type. This would allow operator access to madd in library vectors
> too.

Detecting a "conforming arrangement" is how native types work! Once you wed the 
compiler logic to a particular library implementation, it acquires the worst 
aspects of a native type with the worst aspects of a library type.


> Yeah sure, but I don't think that's fundamentally correct, if you're drifting
> towards typing these things in the language, then you should also start
> considering cast mechanics... and that's a larger topic of debate.
> I don't really think "float4 floatVec = (float4)intVec;" should be a
> reinterpret... surely, as a high level type, this should perform a type conversion?

That's a good point.

> I'm afraid this is become a lot more complicated than it needs to be.
> Can you illustrate your current thoughts/plan, to have it summarised in one
> place.

Support the 10 vector types as basic types, support them with the arithmetic 
infix operators, and use intrinsics for the rest of the operations. I believe 
this scheme:

1. will look better in code, and will be easier to use
2. will allow for better error detection and more comprehensible error messages 
when things are misused
3. will generate better code
4. shouldn't be hard to implement, as I already did most of the work when I did 
the SIMD support for float and double.

> Has it drifted from what you said last night?

Yes.