Changes between Version 2 and Version 3 of NewPlugins

Jan 17, 2011 10:07:42 PM (5 years ago)



  • NewPlugins

    v2 v3  
    101101Backends 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.
    103  * New interface to `Plugin` that is used by `CodeOutput` for custom (named) backends?
    104   * 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?)
    106  * 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.
     103 * New interface to `Plugin` that is used by `CodeOutput` for custom backends?
     104  * TODO FIXME: any assumptions about the backend that would invalidate this general idea?
    108106Currently 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.
     108All backends are given the final Cmm programs in the form of the `RawCmm` datatype.
     110Possible interface: extend `Plugin` with a new constructor, which can have a Cmm backend (TODO: should `DynFlags` argument to plugin be replaced with type `[CommandLineOption]` that is already in use?)
     113type CmmBackendPlugin = Maybe (String,(DynFlags -> FilePath -> [RawCmm] -> IO ()))
     115data Plugin = Plugin {
     116  ...
     117  installCmmBackend :: CmmBackendPlugin
     118  ...
     121defaultPlugin = Plugin {
     122  ...
     123  installCmmBackend = Nothing
     128Then, to use:
     131module Some.Cmm.Plugin (plugin) where
     132import GHCPlugins
     134plugin :: Plugin
     135plugin = defaultPlugin {
     136  installCmmBackend = Just ("Wharble code generator backend", backend)
     139backend :: DynFlags -> FilePath -> [RawCmm] -> IO ()
     140backend dflags filenm flat_absC = do
     141  ...
     144Modifications to compiler pipeline:
     146 * Dynamic code loading can be provided by the same code that works for Core plugins, so this is DONE
     147 * Extending `HscTarget` to recognize the new compilation output case
     148  * Might not be necessary. We can load plugins whenever, and scrutinize the 'installCmmField' to see if there is `Nothing` and if there is,
     149    invoke the normal pipeline, otherwise call our own backend and exit.
     150 * Modify `compiler/main/CodeOutput.lhs` to invoke the plugin callback.
     151  * Plugin-based backends should automatically prioritize over built-in backends?