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

[Iain Buclaw via Digitalmars-d]

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

There are compiler switches for that.  Maybe there should be one
pragma to tweak these compiler switches on a per-function basis,
rather than separately named pragmas.  That way you tell the compiler
what you want, rather than it being part of the language logic to
understand what must be turned on/off internally.

First, assume the language knows nothing about what platform it's
running on, then use that as a basis for suggesting new pragmas that
should be supported everywhere.