On Tuesday, 5 April 2016 at 08:34:32 UTC, Walter Bright wrote:
On 4/4/2016 11:10 PM, 9il wrote:
It is impossible to deduct from that combination that Xeon Phi
has 32 FP registers.
Since dmd doesn't generate specific code for a Xeon Phi, having
a compile time switch for it is meaningless.
"Since the compiler never generates AVX or AVX2" - this is
definitely nor true,
see, for example, LLVM vectorization and SLP vectorization.
dmd is not LLVM.
The particular design and limitations of the dmd backend
shouldn't be used to define D. In the extreme, your argument
would imply that there's no point having version(ARM) built in to
the language, because dmd doesn't support it.
It's entirely practical to compile code with different source
code, link them
*both* into the executable, and switch between them based on
runtime detection
of the CPU.
This approach is complex,
Not at all. Used to do it all the time in the DOS world (FPU vs
emulation).
I just want an unified instrument to receive CT information
about target and
optimization switches. It is OK if this information would have
different
switches on different compilers.
Optimizations simply do not transfer from one compiler to
another, whether the switch is the same or not. They are highly
implementation dependent.
Auto vectorization is only example (maybe bad). I would use
SIMD vectors, but I
need CT information about target CPU, because it is impossible
to build optimal
BLAS kernels without it!
I still don't understand why you cannot just set '-version=xxx'
on the command line and then switch off that version in your
custom code.
So you're suggesting that libraries invent their own list of
versions for specific architectures / CPU features, which the
user then has to specify somehow on the command line?
I want to be able to write code that uses standardised versions
that work across various D compilers, with the user only needing
to type e.g. -march=native on GDC and get the fastest possible
code.
