Austin Seipp
Hi *,
A few days ago a discussion on IRC occurred about the LLVM backend, its current status, and what we could do to make it a rock solid part of GHC for all our users.
As if we needed another reason to do this, it seems that LLVM 3.6 will backwards incompatibly change the alias grammar [1]. This would be quite nasty to treat properly in the backend's current pretty-printing framework so I think we are quickly approaching the point where tighter constraints on acceptable LLVM versions is the only path to sanity. That being said, I'm hopeful that LLVM 3.6 might finally allow us to clean up the LLVM backend. Today I finally sat down and churned out a refactoring of LLVM's prefix data [2]. This should enable a rewrite of tables-next-to-code support which will allow us to severely cut down on the size of the mangler (although sadly I suspect that some mangling will still be necessary on some platforms). I'm going to try to put together a first cut of a TNTC rework tonight. Lastly, as it turns out the LLVM 3.5 rework revealed [3] some optimization opportunties to LLVM which in turn revealed a long-hidden bug in LLVM's implementation of the GHC calling convention (at least on ARM). I've submitted a fix [4] for this as well which will hopefully make it in to LLVM 3.6. Unfortunately, the timing surrounding all of this is relatively terrible. Carter has told me that LLVM 3.6 release might happen around the time of our 7.10 release. As I mentioned above, the grammar change could make supporting both >= 3.6 and <3.6 quite painful. However, given that LLVM 3.5 chokes on our code on ARM, this leaves two options for 7.10, a. Support only LLVM <= 3.4 b. Support only LLVM 3.6, assuming that 3.6 is actually released in time In my opinion both of these options are pretty bad as we are left either supporting a 12-month old, buggy release or a potentially non-existent release. At the moment I'm leaning towards the latter but it's all quite unfortunate. Cheers, - Ben [1] https://github.com/bgamari/ghc/commit/6d80a4925bf6f0221076db9c691d23dd0d83eb... [2] http://reviews.llvm.org/D6444 [3] https://phabricator.haskell.org/D155#14307 [4] http://reviews.llvm.org/D6445