Better X87

[Ben Gamari]

Hi Thomas!


Thomas Jakway <tjakway at 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 at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20161009/5140b52d/attachment.sig>