Proposal: Improving the LLVM backend by packaging it
bgamari.foss at gmail.com
Fri Nov 28 01:37:11 UTC 2014
Austin Seipp <austin at well-typed.com> writes:
> 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 . 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 . 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  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  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
a. Support only LLVM <= 3.4
b. Support only LLVM 3.6, assuming that 3.6 is actually released in
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 472 bytes
Desc: not available
More information about the ghc-devs