Okay, so I took a stab at the build system and getting the analysis plugin at least building, and the results are in this commit:
https://github.com/thoughtpolice/ghc/commit/c30b32fc98a78e322d872b82bed670ee4627ecf0 I'm working on pushing a version that moves most of the logic in this commit directly into a make macro called rules/llvm-plugin.mk so if we ever wanted to write future plugins there isn't as much duplicated logic. It makes the actual llvm/aa-plugin/ghc.mk file 2 lines of code. I'm also interested in looking into LLVM passes etc for GHC-produced code. My git branch somehow ended up corrupt though (my machine crashed in the middle of working on it, but generally this shouldn't be a problem unless it occurs during FS sync,) but I've backed up my work and I'm cloning a new repository while looking... Overall I found by sticking to http://hackage.haskell.org/trac/ghc/wiki/Building/Architecture that *most* of the basic stuff was actually not incredibly hard to understand and modify, but I'm at a loss as to how to add new suffix rules for .cpp files so far. Also some of that page is out of date (e.g. in http://hackage.haskell.org/trac/ghc/wiki/Building/Architecture/Idiom/StandardTargets there are no more PHONY targets, instead the full name merely includes the directory path to build.) I'll take a look at updating it later. Some notes on the commit and food for thought, in no particular order, if this is to be shipped to people. Also things that should be addressed: * It depends on stage1 (or phase=1) finishing. Ideally it doesn't need to do this, at least not at the moment. It would be nice if I could say 'make all_llvm/aa-plugin' anywhere in the tree (like advertised, and it does work!) and skip that build since it doesn't depend on GHC being built at all. * I use llvm-config to get the proper include dirs and library paths as well as linker directives for the analysis pass. So configure.ac now checks for it. Overall this is pretty nice because it does all the hard work of knowing what we actually need to specify, and you can just point the build system to a custom llvm-config if you ever want to build with some other version etc. But it's needed to build the plugin. * Following in these footsteps, should the compiler use llvm-config determined by configure.ac to find the proper `opt` and `llc` utilities to invoke? Right now it just assumes they're either A) in the path or B) you specify them with -pgmlo and -pgmlc respectively. If this is the case then maybe those last two flags should be removed and consolidated with a flag -pgmllconf or something. Either way if you don't do this and get the executables mismatched, I'll bet a dollar the plugin fails to load anyway (and then the whole compilation driver will fail.) * If you wanted to ship this to people in future versions of GHC, I'm pretty sure you're going to need to move/replicate the build rule to work at install time too, because ideally you want to build the eventual shared object file using *their* libraries and installed version of LLVM and its tools, so it can be used safely by their toolchain. Unless we want to ship a version of the .so on every platform built against LLVM 2.7 - 2.9 (we don't.) This also brings up the point of recompiling the plugin using a custom version of LLVM - perhaps there could be a build rule inside llvm/aa-plugin to recompile using a specific llvm-config utility? This would also make testing the plugin against newer LLVM versions much easier. * Because of the implementation the patch only supports an analysis pass stuffed inside a single .cpp file like the one Max wrote. This should probably be lifted and I figure would be easy once we have .cpp suffixes in the build system I guess. See below * The patch probably has cruft/duplication, but I think it should make sense. I'd appreciate directions on a better way to do things like not building if there was no llvm-config found by configure.ac (other than setting the BLDDEP dependency for all_* to the empty string specifically) unless that's fine. * I'm using a g++ floating off in space for creating the plugin. It doesn't look like configure.ac detects the C++ compiler? * I'm confused by adding suffixes. I looked at rules/c-suffix-rules.mk and I'm at a loss for example as to how to structure rules for .cpp files. I think it should be easy to add cases here, but I'm wondering of the significance of things like: $1/$2/build/%.$$($3_osuf) : $1/%.c $$(LAX_DEPS_FOLLOW) $$($1_$2_HC_DEP) | $$$$(dir $$$$@)/. "$$($1_$2_HC)" $$($1_$2_$3_GHC_CC_OPTS) -c $$< -o $$@ Now besides the fact this is where we begin getting into quad-dollar signs, why is there a separate 'build' directory as part of the target? Most of the macros take both the source directory and the 'dist' directory which I believed was where object-files were put - is the 'build' component typically supposed to represent a 'way'? * Overall I found adding a new directory and getting most of the work done pretty easy, actually! It's just starting to get hard to read now that I'm at the point of adding macros... Would it be of interest to anyone else to write something up about adding a new directory/etc? If I don't write one up the above commit is about as simple as it gets I think. Like I said some of the build system commentary pages could be updated. On Mon, Oct 3, 2011 at 5:09 AM, Simon Marlow <[email protected]> wrote: > On 30/09/2011 09:54, Max Bolingbroke wrote: >> >> Hi GHCers, >> >> As those of you who use the LLVM backend know, it often doesn't >> optimise as aggressively as you would like. The reason for this is >> often to do with aliasing. I've written a blog post outlining the >> problem and a solution, in the form of a GHC-specific alias analyser >> that tells LLVM that the heap does not alias with the stack: >> http://blog.omega-prime.co.uk/?p=135 >> >> I think it might be desirable to have this pass in GHC, so we can use >> it whenever the user compiles with -fllvm. Perhaps someone could help >> me make the build system do what I want, though? Basically, if the >> LLVM backend is enabled I need to be able to compile a single C++ file >> to a .dynlib/.so/.dll, linking it against the LLVM .dynlib. This >> shared object must also be installed onto the user's system by "make >> install", and the compiler must know the fully-qualified path to that >> .dynlib so that I can have the driver pipeline invoke LLVM's "opt" >> tool with the path from which to dynamically load the custom pass. > > This shouldn't be too hard, but you'll need to write some Makefile code to > make it happen - we don't have anything like this already in the build > system. > >> My previous experiences with the build system have not been good, so >> I'm a bit lost as to where to start with all this! > > I'd just make a subdirectory, put your .cpp file in it, and create a > Makefile with rules to compile the file and install it. We should probably > have a standard suffix rule for compiling .cpp files, so that things like > SRC_CPLUSPLUS_OPTS can be used. Maybe you'll need some autoconf stuff to > find the appropriate way to link against the LLVM libraries. > > Cheers, > Simon > > > _______________________________________________ > Cvs-ghc mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/cvs-ghc > -- Regards, Austin _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
