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.
