On 4/5/2016 2:03 AM, John Colvin wrote:
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.
There's a line between trying to standardize everything and letting add-on
libraries be free to innovate.
Besides, I think it's a poor design to customize the app for only one SIMD type.
A better idea (I've repeated this ad nauseum over the years) is to have n
modules, one for each supported SIMD type. Compile and link all of them in, then
detect the SIMD type at runtime and call the corresponding module. (This is how
the D array ops are currently implemented.)
My experience with command line FPU switches is few users understand what they
do and even fewer use them correctly.
In fact, I suspect that having a command line FPU switch is too global a hammer.
A pragma set in just the functions that need it might be much better.
-------
In any case, this is not a blocker for getting the library designed, built and
debugged.
