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 <
tjakway@nyu.edu> wrote:
OK, makes sense, thanks.
On 10/09/2016 02:14 PM, Ben Gamari wrote:
Hi Thomas!
Thomas Jakway <tjakway@nyu.edu> 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.
git log -p says this was apparently written in 2009 by
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
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