SIMD support...

[Peter Alexander]

On 7/01/12 9:28 PM, Andrei Alexandrescu wrote:
> What's built inside the compiler is like axioms in math, and what's
> library is like theorems supported by the axioms. A good language, just
> like a good mathematical system, has few axioms and many theorems. That
> means the system is coherent and expressive. Hardwiring stuff in the
> language definition is almost always a failure of the expressive power
> of the language.

Yes, but when it comes to register allocation and platform specific 
instruction selection, that really is the job of the compiler. It is not 
something that can be done in a library (without rewriting the compiler 
in the language, which defeats the purpose of having a language in the 
first place).

I agree that the language should add the minimum number of features to 
support what we want, although in this case (due to how 
platform-specific the solutions are) I think it simply requires a lot of 
work in the compiler.


> We should start from what the user wants to accomplish. Then figure how
> to express that within the language. And only lastly, when needed,
> change the language to mandate lowering constructs to the MINIMUM EXTENT
> POSSIBLE into constructs that can be handled within the existing
> language.

I agree.

Essentially, we need at least:

- Some type (or types) that map directly to SIMD registers.
- The type must be separate from static arrays (aligned or not).
- Automatic register allocation, just like other primitive types.
- Automatic instruction scheduling.
- Ability to specify what instructions to use.

I agree with Manu that we should just have a single type like __m128 in 
MSVC. The other types and their conversions should be solvable in a 
library with something like strong typedefs.

As the *sole* reason for this enhancement is performance, the compiler 
absolutely must have all the information it needs to produce optimal code.


> I am a bit worried about the increasing radicalization of the discussion
> here, but recent statements come in frontal collision with my core
> principles, which I think stand on solid evidential ground. I am
> appealing for building consensus and staying principled instead of
> reaching for the cheap solution. If we do the latter, it's quite likely
> we'll regret it later.

We also need to be pragmatic. There is no point defining a perfect, 
modular, clean solution to the problem if it is going to take years to 
realize. In years, the problem may not exist anymore. This is especially 
true when it comes to hardware issues like the one we are discussing here.