I actually think we should either remove x87 support, or make it not the default and make it more cleanly factored out from the rest of x86 code gen Improving x87 as a getting feet wet in a focused way sounds like a great low risk way. I think we should change to having code gen on x86-32 default to sse based float and double by default with mx87 or whatever we wanna call it / is the standard convention for naming that be soemthing that has to be explicitly asked for As far as I can tell the only current Intel 32bit chips that don't support sse based float and double computation are the ones that are meant to compete with atmel / arduino etc, like the Edison / quark boards https://en.m.wikipedia.org/wiki/Intel_Quark , as all the slightly beefier offerings like the atom series of low power systems all have sse support. @thomas I'm happy to help mentor / collab / whatever on this, since I've been wanting to cleanup this stuff for a while. Either way, I strongly support the work start with a warm up patch to swap the defaults. X87 floating point causes a lot of heart ache for those who fit. Expect it / and it definitely makes it so that results on 32bit by default don't match 32bit or even optimization levels On Sunday, October 9, 2016, Thomas Jakway wrote:

OK, makes sense, thanks.

On 10/09/2016 02:14 PM, Ben Gamari wrote:

...

Hi Thomas!

Thomas Jakway writes:

I was looking through compiler/nativeGen/X86/Instr.hs

...

<https://github.com/ghc/ghc/blob/master/compiler/nativeGen/ X86/Instr.hs#L71> and it's pretty hard not to notice the (hilarious) diatribe about the horror that is x87.

Reading these notes is one of the joys of working on GHC.

...

Ben.Lippmeier@anu.edu.au (92ee78e03c3670f56ebbbbfb0f67a00f9ea1305f).

Since this has survived in X86/ all this time I'm guessing this is still an issue (another guess: we've gotten by because of SSE?). Is there any interest in improving x87 code generation? And if so, has anyone tried before?

As far as I know this is indeed still an issue, but one that (I would guess) relatively few people really feel. There are two reasons for

git log -p says this was apparently written in 2009 by this,

* We have the LLVM backend which users needing high performance numerics tend to gravitate towards

* We have -msse2 which is used by default on x86_64 (which is most users as this point).

My impression is that this is still a "problem" but, unless you are yourself actively affected by it, there are probably more important ways to contribute (e.g. fix up the graph coloring register allocator).

If you did want to fix up x87 support, I think it would preferable to do so in a way that avoids complicating the register allocator; some day the monster that is x87 will die and we'd prefer not to have to rip out more of its tentacles from the code generator than necessary. I think the "more clever" approach described in the note would probably be a good start: retain the virtual "registers" but try to be more clever about assigning them to stack entries by looking at more than one instruction at once.

Cheers,

- Ben

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs