Why don't we switch to C like floating pointed arithmetic instead of automatic expansion to reals?

Iain Buclaw via Digitalmars-d digitalmars-d at puremagic.com
Sat Aug 6 04:10:18 PDT 2016


On 6 August 2016 at 12:07, Ilya Yaroshenko via Digitalmars-d
<digitalmars-d at puremagic.com> 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
>> <digitalmars-d at puremagic.com> 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.


More information about the Digitalmars-d mailing list