bscarlet
commented
7 years ago That page does say that
The LLVM Haskell binding (first option) wasn't used as it represents LLVM at a very high level
but the "first option" it lists is linked to http://hackage.haskell.org/package/llvm, not to this package. That other set of llvm bindings existed first, then the GHC llvm backend was written, then I created llvm-general precisely to get past the limitations imposed by high-level interface of the older llvm package. I believe llvm-general's API is already roughly what the GHC llvm backend would need.
I would certainly like to see llvm-general used in the GHC, but there are some remaining impediments.
As documented at that wiki, currently the ghc backend produces serialized llvm assembly as files. Currently, llvm-general-pure provides a haskell representation of that llvm assembly, and llvm-general is all the machinery to lower and raise that haskell representation to & from llvm's C++ representation, as well as interfaces to use llvm's C++ code to do all sorts of stuff to that C++ representation, including serializing it various ways.
If GHC could produce the haskell representation used in llvm-general-pure (which is logically at the same level as the text it currently produces), then various options would become possible.
Firstly, one could use llvm-general to mimic what GHC currently does, serializing the tree and letting the rest of the current GHC backend take over running the separate llvm binaries to process the resulting files. However, that would come at the cost of need GHC to link in llvm-general and so llvm. If one were to re-implement the pretty printing from the haskell ast to the text form in llvm-general-pure (cutting out the llvm-general / llvm C++ code from the middle), then that cost could be removed.
Secondly, one could skip serializing the tree at all, and go straight from the Haskell tree to the C++ tree to an optimized C++ tree to emitting machine code.
The GHC wiki indicates that llvm-general was not chosen for GHC's LLVM backend because it is too high level. A lower level API should also be provided.
This may require somehow calling into C++ from Haskell. This should be doable by writing a few C++ stubs; I don't think the entire API needs to be exposed.