Better X87

[Carter Schonwald]

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 at nyu.edu> wrote:

> OK, makes sense, thanks.
>
> On 10/09/2016 02:14 PM, Ben Gamari wrote:
>
>> 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
>>
>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20161010/32420ad0/attachment-0001.html>