On 5/18/2016 2:54 AM, Ethan Watson wrote:
On Wednesday, 18 May 2016 at 08:55:03 UTC, Walter Bright wrote:
MSVC doesn't appear to have a switch that does what you ask for
I'm still not entirely sure what the /fp switch does for x64 builds. The
documentation is not clear in the slightest and I haven't been able to find any
concrete information. As near as I can tell it has no effect as the original
behaviour was tied to how it handles the x87 control words. But it might also be
possible that the SSE instructions emitted can differ depending on what
operation you're trying to do. I have not dug deep to see exactly how the code
gen differs. I can take a guess that /fp:precise was responsible for promoting
my float to a double to call CRT functions, but I have not tested that so that's
purely theoretical at the moment.
Of course, while this conversation has mostly been for compile time constant
folding, the example of passing a value from the EE and treating it as a
constant in the VU is still analagous to calculating a value at compile time in
D at higher precision than the instruction set the runtime code is compiled to
work with.
/arch:sse2 is the default with MSVC x64 builds (Xbox One defaults to /arch:avx),
and it sounds like the DMD has defaulted to sse2 for a long time. The exception
being the compile time behaviour. That compile time behaviour conforming to the
the runtime behaviour is an option I want, with the default being whatever is
decided in here. Executing code at compile time at a higher precision than what
SSE dictates is effectively undesired behaviour for our use cases.
And in cases where we compile code for another architecture on x64 (let's say
ARM code with NEON instructions, as it's the most common case thanks to iOS
development) then it would be forced to fallback to the default. Fine for most
use cases as well. It would be up to the user to compile their ARM code on an
ARM processor to get the code execution match if they need it.
Again, even if the precision matches, the rounding will NOT match, and you will
get different results randomly dependent on the exact operand values.
If those differences matter, then you'll randomly be up all night debugging it.
If you're willing to try the approach I mentioned, it'll cost you a bit more
time up front, but may save a lot of agony later.
