Design discussion for atomic primops to land in 7.8
jwlato at gmail.com
Mon Aug 26 08:37:28 CEST 2013
On Sun, Aug 25, 2013 at 11:01 PM, Ben Lippmeier <benl at ouroborus.net> wrote:
> On 23/08/2013, at 3:52 AM, Ryan Newton wrote:
> > Well, what's the long term plan? Is the LLVM backend going to become
> the only backend at some point?
> I wouldn't argue against ditching the NCG entirely. It's hard to justify
> fixing NCG performance problems when fixing them won't make the NCG faster
> than LLVM, and everyone uses LLVM anyway.
This is not true. I don't believe I've ever seen the LLVM backend compile
more quickly than the NCG, it usually takes significantly longer, and for
at least some (most?) projects produces worse output.
I don't have anything against the LLVM backend in principle*, but at
present it's not as good as the NCG for us.
We're going to need more and more SIMD support when processors supporting
> the Larrabee New Instructions (LRBni) appear on people's desks. At that
> time there still won't be a good enough reason to implement those
> instructions in the NCG.
How about that the NCG is better than LLVM? ;)
In all seriousness, I'm quite sympathetic to the desire to support only one
backend, and LLVM can offer a lot (SIMD fallbacks, target architectures,
etc). But at present, in my experience the LLVM backend doesn't really
live up to what I've seen claimed for it. Given that, I think it's a bit
premature to talk of dropping the NCG.
 Ok, I do have one issue with LLVM. It's always struck me as very
brittle, with a lot of breakages between versions. Given that I just tried
ghc -fllvm with LLVM-3.3 and the compiler bailed out due to a bad object
file, my impression of brittleness doesn't seem likely to change any time
soon. Given that LLVM releases major versions predictably often, I don't
know that I want ghc devs spending time chasing after them. But in
principle it seems the right thing to do.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs