I've collected the main points of this discussion on the wiki.
http://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/ReplacingNCG
Ben.
On 28/08/2013, at 2:51 AM, Austin Seipp wrote:
> Well, what's the long term plan? Is the LLVM backend going to
become the only bac
Austin also raises an important point:
Its high time we explore changes to the ABI/per architecture calling
convention and how they might impact performance.
I think this is something worth exploring after the 7.8 release
(but not in the next month of prerelease engineering, though I need to sus
To do this, IMO we'd also really have to start shipping our own copy
of LLVM. The current situation (use what we have configured or in
$PATH) won't really become feasible later on.
On platforms like ARM where there is no NCG, the mismatches can become
super painful, and it makes depending on certa
On 26/08/13 08:17, Ben Lippmeier 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
ma
> > 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
On Sun, Aug 25, 2013 at 11:01 PM, Ben Lippmeier 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
> fix
2013/8/26 Ben Lippmeier
>
> 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 wh
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 f
Well, what's the long term plan? Is the LLVM backend going to become the
only backend at some point?
On Thu, Aug 22, 2013 at 1:43 PM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:
> Hey Ryan,
> you raise some very good points.
>
> The most important point you raise (I think) is this:
>
Hey Ryan,
you raise some very good points.
The most important point you raise (I think) is this:
it would be very very nice to (where feasible) to add analogous machinery
to the native code gen, so that its not falling behind the llvm one quite
as much.
at least for these atomic operations (unlik
There's a ticket that describes the design here:
http://ghc.haskell.org/trac/ghc/ticket/8157#comment:1
It is a fairly simple extension of the casMutVar# that has been in since
7.2. The implementation is on the `atomics` branch currently.
Feel free to add your views either here or on that task
11 matches
Mail list logo
