Design discussion for atomic primops to land in 7.8

[John Lato]

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.

My $0.02,
John

[1] 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...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130826/480e5740/attachment.htm>