Hi Thomas!
Thomas Jakway <tjak...@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.lippme...@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
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
