November 07, 2016
https://issues.dlang.org/show_bug.cgi?id=13474

--- Comment #26 from Walter Bright <bugzilla@digitalmars.com> ---
> I think that's well covered by adding an intrinsic,

I produced a PR request for that in druntime. Nobody liked it, and it languishes unpulled.

https://github.com/dlang/druntime/pull/1621

--
November 07, 2016
https://issues.dlang.org/show_bug.cgi?id=13474

--- Comment #27 from Walter Bright <bugzilla@digitalmars.com> ---
> stop supporting targets without xmm regs

A couple problems with this:

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?)

2. It's not a simple matter of turning it on, even though dmd generates XMM code for OSX 32 bit. The trouble is in getting the stack aligned to 16 bytes. The Linux way of doing that is different from OSX, so there's some significant dev work to do to match it.

I believe that making faster 64 bit code should have priority over making faster 32 bit code, based on the idea that users who feel the need for speed are going to be using -m64.

--
November 07, 2016
https://issues.dlang.org/show_bug.cgi?id=13474

--- Comment #28 from yebblies <yebblies@gmail.com> ---
(In reply to Walter Bright from comment #26)
> > I think that's well covered by adding an intrinsic,
> 
> I produced a PR request for that in druntime. Nobody liked it, and it languishes unpulled.
> 
> https://github.com/dlang/druntime/pull/1621

I must have missed that.  I'm happy to review/merge dmd changes related to that.  I'm worried the other approach will just cause a performance issue that's impossible to work around.

> 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?  Embedded system users are exactly the people who are setting gcc switches correctly.

> 2. It's not a simple matter of turning it on, even though dmd generates XMM code for OSX 32 bit. The trouble is in getting the stack aligned to 16 bytes. The Linux way of doing that is different from OSX, so there's some significant dev work to do to match it.

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

> I believe that making faster 64 bit code should have priority over making faster 32 bit code, based on the idea that users who feel the need for speed are going to be using -m64.

It's much easier to switch over to m64 on linux, which is why I'm still using m32 on windows.  One day...

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?

--
November 07, 2016
https://issues.dlang.org/show_bug.cgi?id=13474

--- Comment #29 from Walter Bright <bugzilla@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?

--
November 10, 2016
https://issues.dlang.org/show_bug.cgi?id=13474

--- Comment #30 from github-bugzilla@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/6db2246e97c790e0988f024ccb25d0fb090d609a fix Issue 13474 - Discard excess precision for float and double (x87)

https://github.com/dlang/dmd/commit/b9d6be259e2e54c66d8361675b65f717dd5e3fc4 Merge pull request #6247 from WalterBright/fix13474

fix Issue 13474 - Discard excess precision for float and double (x87)

--
November 10, 2016
https://issues.dlang.org/show_bug.cgi?id=13474

github-bugzilla@puremagic.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--
December 27, 2016
https://issues.dlang.org/show_bug.cgi?id=13474

--- Comment #31 from github-bugzilla@puremagic.com ---
Commits pushed to scope at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/6db2246e97c790e0988f024ccb25d0fb090d609a fix Issue 13474 - Discard excess precision for float and double (x87)

https://github.com/dlang/dmd/commit/b9d6be259e2e54c66d8361675b65f717dd5e3fc4 Merge pull request #6247 from WalterBright/fix13474

--
January 16, 2017
https://issues.dlang.org/show_bug.cgi?id=13474

--- Comment #32 from github-bugzilla@puremagic.com ---
Commits pushed to newCTFE at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/6db2246e97c790e0988f024ccb25d0fb090d609a fix Issue 13474 - Discard excess precision for float and double (x87)

https://github.com/dlang/dmd/commit/b9d6be259e2e54c66d8361675b65f717dd5e3fc4 Merge pull request #6247 from WalterBright/fix13474

--
1 2 3 4
Next ›   Last »