Aaron,
The LLVM backend needs some care and attention
I’m sure you are right about this. Could you become one of the people offering that care and attention. Who are the GHC developers? They are simply volunteers who make time to give something back to their community, and GHC relies absolutely on their commitment and expertise. So do please join in if you can; it’s clearly something you care about, and have some knowledge of.
With thanks and best wishes,
Simon
From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Aaron Friel
Sent: 02 January 2014 03:03
To: Carter Schonwald
Cc: ghc-devs@haskell.org
Subject: Re: LLVM and dynamic linking
Because I think it’s going to be an organizational issue and a duplication of effort if GHC is built one way but the future direction of LLVM is another.
Imagine if GCC started developing a new engine and it didn’t work with one of the biggest, most regular consumers of GCC. Say, the Linux kernel, or itself. At first, the situation is optimistic - if this engine doesn’t work for the project that has the smartest, brightest GCC hackers potentially looking at it, then it should fix itself soon enough. Suppose the situation lingers though, and continues for months without fix. The new GCC backend starts to become the default, and the community around GCC advocates for end-users to use it to optimize code for their projects and it even becomes the default for some platforms, such as ARM.
What I’ve described is analogous to the GHC situation - and the result is that GHC isn’t self-hosting on some platforms and the inertia that used to be behind the LLVM backend seems to have stagnated. Whereas LLVM used to be the “new hotness”, I’ve noticed that issues like Trac #7787 no longer have a lot of eyes on them and externally it seems like GHC has accepted a bifurcated approach for development.
I dramatize the situation above, but there’s some truth to it. The LLVM backend needs some care and attention and if the majority of GHC devs can’t build GHC with LLVM, then that means the smartest, brightest GHC hackers won’t have their attention turned toward fixing those problems. If a patch to GHC-HEAD broke compilation for every backend, it would be fixed in short order. If a new version of GCC did not work with GHC, I can imagine it would be only hours before the first patches came in resolving the issue. On OS X Mavericks, an incompatibility with GHC has led to a swift reaction and strong support for resolving platform issues. The attention to the LLVM backend is visibly smaller, but I don’t know enough about the people working on GHC to know if it is actually smaller.
The way I am trying to change this is by making it easier for people to start using GHC (by putting images on Docker.io) and, in the process, learning about GHC’s build process and trying to make things work for my own projects. The Docker image allows anyone with a Linux kernel to build and play with GHC HEAD. The information about building GHC yourself is difficult to approach and I found it hard to get started, and I want to improve that too, so I’m learning and asking questions.
From: Carter Schonwaldmailto:carter.schonwald@gmail.com
Sent: Wednesday, January 1, 2014 5:54 PM
To: Aaron Frielmailto:aaron@frieltek.com
Cc: ghc-devs@haskell.orgmailto:ghc-devs@haskell.org
7.8 should have working dylib support on the llvm backend. (i believe some of the relevant patches are in head already, though Ben Gamari can opine on that)
why do you want ghc to be built with llvm? (i know i've tried myself in the past, and it should be doable with 7.8 using 7.8 soon too)
On Wed, Jan 1, 2014 at 5:38 PM, Aaron Friel