[Issue 13474] Discard excess precision for float and double (x87)

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13474

--- Comment #29 from Walter Bright <bugzilla at digitalmars.com> ---
(In reply to yebblies from comment #28)
> (In reply to Walter Bright from comment #26)
> I must have missed that.  I'm happy to review/merge dmd changes related to
> that.

No dmd changes are necessary, it will work as is. I designed it as an intrinsic
in case some future code gen scheme will cause it to not work.

> I'm worried the other approach will just cause a performance issue
> that's impossible to work around.

It could be worked around by using reals as temporaries instead of doubles, but
few programmers have that level of understanding of how floating point works.


> > 1. It is unknown what 32 bit x86 CPUs are used for embedded systems. I dislike adding more codegen switches, because every switch doubles the time it takes to run the test suite, and few developers set them correctly. (Who ever sets that blizzard of switches gcc has correctly?)
> 
> Who is using dmd on an embedded system?  Why?

I don't know. I'm reluctant to just break all their code just because I am
ignorant of them.

> Embedded system users are
> exactly the people who are setting gcc switches correctly.

In my experience with embedded systems developers, they aren't any more
sophisticated with detailed feature switch settings than any other systems code
developer. Most just copy the switch settings from project to project, in the
process losing any information about why those settings were set to begin with.

> Then again, wouldn't using unaligned loads/stores still be
> faster than using the x87?  Last I checked, it was... not fast.

I don't know. I also overlooked another point - the 32 bit ABI still uses the
ST0 register for floating point returns. Not sure what gcc does about that.
Anyhow, there is clearly some not insignificant engineering work to be done for
that. It's a question of whether it is worth it.

> Can you put together a dmd PR to go with druntime 1621?  I'm guessing it's
> pretty easy, since a new OPER will default to not being optimized?

I as a mentioned, no dmd changes are currently necessary.

One last point. Yes, the intrinsics will work and will be a more efficient
solution. The problem, though, is people will port code that works, or will
type in code from a book, and then it will not work, and they will blame D. Not
many will know just where the intrinsics will need to be inserted. How many
here realized the store to t was the problem?

--