https://issues.dlang.org/show_bug.cgi?id=13474
--- Comment #29 from Walter Bright <[email protected]> --- (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? --
