On Saturday, 6 August 2016 at 11:10:18 UTC, Iain Buclaw wrote:
On 6 August 2016 at 12:07, Ilya Yaroshenko via Digitalmars-d
<[email protected]> wrote:
On Saturday, 6 August 2016 at 10:02:25 UTC, Iain Buclaw wrote:
On 6 August 2016 at 11:48, Ilya Yaroshenko via Digitalmars-d
<[email protected]> wrote:
On Saturday, 6 August 2016 at 09:35:32 UTC, Walter Bright
wrote:
[...]
OK, then we need a third pragma,`pragma(ieeeRound)`. But
`pragma(fusedMath)`
and `pragma(fastMath)` should be presented too.
[...]
It allows a compiler to replace two arithmetic operations
with single composed one, see AVX2 (FMA3 for intel and FMA4
for AMD) instruction set.
No pragmas tied to a specific architecture should be allowed
in the language spec, please.
Then probably Mir will drop all compilers, but LDC
LLVM is tied for real world, so we can tied D for real world
too. If a
compiler can not implement optimization pragma, then this
pragma can be just
ignored by the compiler.
If you need a function to work with an exclusive instruction
set or something as specific as use of composed/fused
instructions, then it is common to use an indirect function
resolver to choose the most relevant implementation for the
system that's running the code (a la @ifunc), then for the
targetted fusedMath implementation, do it yourself.
What do you mean by "do it yourself"? Write code using FMA GCC
intrinsics? Why I need to do something that can be automated by a
compiler? Modern approach is to give a hint to the compiler
instead of write specialised code for different architectures.
It seems you have misunderstood me. I don't want to force
compiler to use explicit instruction sets. Instead, I want to
give a hint to a compiler, about what math _transformations_ are
allowed. And this hints are architecture independent. A compiler
may a may not use this hints to optimise code.
