|Version 1 (modified by 6 years ago) (diff),|
New Plugins work
Max originally did the work on GHC plugins in his GSoC 2008 hacking sprint. It involved the implementation of annotations as well as a dynamic loading aspect to GHC. While the annotations work was included into GHC HEAD, the loading infrastructure was not. This document describes the current work (as of 2011) to get it integrated into GHC HEAD so you can write core plugins, and future extensions to the interface, primarily writing C-- passes, and new backends.
1/17/11: I (Austin Seipp) am working on getting the patch cleaned up a little more and tidying it up before it gets integrated. Still need testsuite patches.
NB. Ridiculously incomplete writing/documentation.
Get GHC from its HEAD repository, and apply this patch:
Then build GHC like normal.
Now GHC understands the
-fplugin-arg options. You essentially install plugins for GHC by
cabal installing them, and then calling GHC in the form of:
$ ghc -fplugin=Some.Plugin.Module -fplugin-arg=Some.Plugin.Module:no-fizzbuzz a.hs
Some.Plugin.Module should export a symbol named 'plugin' - see the following repository for an example that does Common Subexpression Elimination:
Basic overview of the plugins API for Core
Plugins for Cmm
Aside from manipulating the core language, we would also like to manipulate the C-- representation GHC generates for modules too.
The new code generator (more precisely, the optimizing conversion from STG to Cmm part of GHC) based on hoopl for dataflow analysis is going to be merged into HEAD Real Soon Now. It would be best perhaps to leave this part of the interface alone until it is merged - clients of the interface could then use hoopl to write dataflow passes for Cmm.
- New code generator is based on several phases:
- Conversion from STG to Cmm
- Basic optimisations
- CPS Conversion
- More basic optimisations on CPS form
- Conversion to old Cmm representation, then passed to backend code generator.
- We need some sort of interface to describe how to insert it into the pipeline - is the Core approach best here?
- Add new interface to
installCmmPass, that installs a pass of type
CmmGraph -> CmmGraphinto the optimization pipeline somehow.
Backends could be written using plugins as well. This would make it possible to pull the LLVM code generator out of GHC, and into a
cabal package using the llvm bindings on hackage, among other crazy things.
- New interface to
Pluginthat is used by
CodeOutputfor custom (named) backends?
- TODO FIXME current assumptions about output files/etc that would make this infeasible? Not sure where e.g. the linker is finally invoked in case you even wanted to write a backend that did something super-fancy involving duping it (LTO?)
- Names would be needed since we cannot arbitrarily extend
HscTarget- we would need some new case such as
HscPluginBackend String, but this is sort of ugly.
Currently the new code generator converts the new Cmm based on Hoopl to the old Cmm representation when in use, so it can be passed onto the current native code generators. So adding this part of the API is rather independent of the current status of the new backend - the backend API just has to use the old CMM representation for conversion.