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<div><br></div><div>Improving x87 as a getting feet wet in a focused way sounds like a great low risk way. </div><div><br></div><div>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 </div><div><br></div><div>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 <a href="https://en.m.wikipedia.org/wiki/Intel_Quark">https://en.m.wikipedia.org/wiki/Intel_Quark</a> , as all the slightly beefier offerings like the atom series of low power systems all have sse support.  </div><div><br></div><div>@thomas I'm happy to help mentor / collab / whatever on this, since I've been wanting to cleanup this stuff for a while. </div><div><br></div><div>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 <span></span><br><br>On Sunday, October 9, 2016, Thomas Jakway <<a href="mailto:tjakway@nyu.edu">tjakway@nyu.edu</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">OK, makes sense, thanks.<br>
<br>
On 10/09/2016 02:14 PM, Ben Gamari wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Thomas!<br>
<br>
<br>
Thomas Jakway <<a>tjakway@nyu.edu</a>> writes:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I was looking through compiler/nativeGen/X86/Instr.h<wbr>s<br>
<<a href="https://github.com/ghc/ghc/blob/master/compiler/nativeGen/X86/Instr.hs#L71" target="_blank">https://github.com/ghc/ghc/bl<wbr>ob/master/compiler/nativeGen/<wbr>X86/Instr.hs#L71</a>><br>
and it's pretty hard not to notice the (hilarious) diatribe about the<br>
horror that is x87.<br>
<br>
</blockquote>
Reading these notes is one of the joys of working on GHC.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
git log -p says this was apparently written in 2009 by<br>
<a>Ben.Lippmeier@anu.edu.au</a> (92ee<wbr>78e03c3670f56ebbbbfb0f67a00f9e<wbr>a1305f).<br>
<br>
Since this has survived in X86/ all this time I'm guessing this is still<br>
an issue (another guess: we've gotten by because of SSE?).  Is there any<br>
interest in improving x87 code generation? And if so, has anyone tried<br>
before?<br>
<br>
</blockquote>
As far as I know this is indeed still an issue, but one that (I would<br>
guess) relatively few people really feel. There are two reasons for<br>
this,<br>
<br>
  * We have the LLVM backend which users needing high performance<br>
    numerics tend to gravitate towards<br>
<br>
  * We have -msse2 which is used by default on x86_64 (which is most<br>
    users as this point).<br>
<br>
My impression is that this is still a "problem" but, unless you are<br>
yourself actively affected by it, there are probably more important<br>
ways to contribute (e.g. fix up the graph coloring register allocator).<br>
<br>
If you did want to fix up x87 support, I think it would preferable to do<br>
so in a way that avoids complicating the register allocator; some day<br>
the monster that is x87 will die and we'd prefer not to have to rip out<br>
more of its tentacles from the code generator than necessary. I think<br>
the "more clever" approach described in the note would probably be<br>
a good start: retain the virtual "registers" but try to be more clever<br>
about assigning them to stack entries by looking at more than one<br>
instruction at once.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>
</blockquote>
<br>
______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a>ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>