David wrote, > Issues > ------ > Issues that might need to be resolved before merging the patch: > > 1. Developed in isolation by 1 person with no Haskell knowledge at first. So > usual issues with that may apply, misused data structures, bad style... ect. > Criticisms of the code are very welcome. There are some specific notes on > what I think may be wrong with the code atm in 'compiler/llvmGen/NOTES'.
I have seen worse code in GHC, *much* worse ;) > 2. The back-end has a LLVM binding of sorts, this binding is similar in > design to say the Cmm representation used in GHC. It represents the LLVM > Assembly language using a collection of data types and can pretty print it > out correctly. This binding lives in the 'compiler/llvmGen/Llvm' folder. > Should this binding be split out into a separate library? That library would be a build requirement for GHC, then. It may be useful to separate it out for other projects that want to use it, but for GHC, I don't think it would help anything, so I wouldn't worry about that until somebody actually wants to use it for something else. > 3. As mentioned above, LLVM needs to be patched to work with a registered > build of GHC. If the llvm back-end was merged, how would this be handled? I > would suggest simply carrying the patch with some instructions on how to use > it in the GHC repo. People using GHC head could be expected to grab the LLVM > source code and apply the patch themselves at this stage. I think, we should bundle LLVM with GHC and auto apply the patch at build boot time (in the same manner that gmp is bundled and patched and libffi is bundeled). There is also an obvious place where the LLVM tarbar would go, namely http://darcs.haskell.org/ghc-tarballs/ Why should we bundle? Because we want to make life for current and prospective GHC devs as easy as possible. A build dependency that you have to download, patch, and install manually complicates the build instructions and is annoying. Given it has to be patched, package managers —such as those for various Linux distros— won't help either. Moreover, the day will come where LLVM gets updated and GHC requires a tweak to work with the new LLVM and people will download the wrong version and spam the support list. No fun. My vote is for merging the LLVM backend as it is (with an LLVM tarball in ghc-tarballs/). It needs to be an optional build option for now, though, as it requires to switch off TABLES_NEXT_TO_CODE. Once it is in, it's much easier for people to try it, play with it, and improve it. Manuel _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
