Changes between Version 2 and Version 3 of NewPlugins


Ignore:
Timestamp:
Jan 17, 2011 10:07:42 PM (3 years ago)
Author:
thoughtpolice
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • 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 [http://hackage.haskell.org/package/llvm llvm] bindings on hackage, among other crazy things. 
    102102 
    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?) 
    105  
    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? 
    107105 
    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. 
     107 
     108All backends are given the final Cmm programs in the form of the `RawCmm` datatype. 
     109 
     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?) 
     111 
     112{{{ 
     113type CmmBackendPlugin = Maybe (String,(DynFlags -> FilePath -> [RawCmm] -> IO ())) 
     114 
     115data Plugin = Plugin { 
     116  ... 
     117  installCmmBackend :: CmmBackendPlugin 
     118  ... 
     119} 
     120 
     121defaultPlugin = Plugin { 
     122  ... 
     123  installCmmBackend = Nothing 
     124} 
     125 
     126}}} 
     127 
     128Then, to use: 
     129 
     130{{{ 
     131module Some.Cmm.Plugin (plugin) where 
     132import GHCPlugins 
     133 
     134plugin :: Plugin 
     135plugin = defaultPlugin { 
     136  installCmmBackend = Just ("Wharble code generator backend", backend) 
     137} 
     138 
     139backend :: DynFlags -> FilePath -> [RawCmm] -> IO () 
     140backend dflags filenm flat_absC = do 
     141  ... 
     142}}} 
     143 
     144Modifications to compiler pipeline: 
     145 
     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?