Does it sound a good idea to implement "backend plugins"?

Moritz Angermann moritz.angermann at
Thu Oct 4 22:44:00 UTC 2018

A long time ago, I’ve tried to inject plugin logic to allows some control over the driver pipeline (phase ordering) and hooking various code gen related functions.


At that time I ran into issues that might simply not exist with plugins anymore today, but I haven’t looked.

The whole design wasn’t quite right and injects everything into the dynflags.  Also ghc wanted to be able to compile the plugin on the fly, but I needed the plugin to be loaded very early during the startup phase to exert enough control of the rest of the pipeline through the plugin.


Sent from my iPhone

On 5 Oct 2018, at 1:52 AM, Shao, Cheng <cheng.shao at> wrote:

>> Adding "pluggable backends" to spin up new targets seems to require quite a bit of additional infrastructure for initialising a library directory and package database. But there are probably more specific use cases that need inspecting/modifying STG or Cmm where plugins would already be useful in practice.
> I think setting up a new global libdir/pkgdb is beyond the scope of
> backend plugins. The user shall implement his/her own boot script to
> configure for the new architecture, generate relevant headers, run
> Cabal's Setup program to launch GHC with the plugin loaded.
>> Hooks (or rather their locations in the pipeline) are rather ad hoc by nature, but for Asterius a hook that takes Cmm and takes over from there seems like a reasonable approach given the current state of things. I think the Cmm hook you implemented (or something similar) would be perfectly acceptable to use for now.
> For the use case of asterius itself, indeed Hooks already fit the use
> case for now. But since we seek to upstream our newly added features
> in our ghc fork back to ghc hq, we should upstream those changes early
> and make them more principled. Compared to Hooks, I prefer to move to
> Plugins entirely since:
> * Plugins are more composable, you can load multiple plugins in one
> ghc invocation. Hooks are not.
> * If I implement the same mechanisms in Plugins, this can be
> beneficial to other projects. Currently, in asterius, everything works
> via a pile of hacks upon hacks in ghc-toolkit, and it's not good for
> reuse.
> * The newly added backend plugins shouldn't have visible
> correctness/performance impact if they're not used, and it's just a
> few local modifications in the ghc codebase.
>>> On Thu, Oct 4, 2018 at 3:56 PM Shao, Cheng <cheng.shao at> wrote:
>>> Hi all,
>>> I'm thinking of adding "backend plugins" in the current Plugins
>>> mechanism which allows one to inspect/modify the IRs post simplifier
>>> pass (STG/Cmm), similar to the recently added source plugins for HsSyn
>>> IRs. This can be useful for anyone creating a custom GHC backend to
>>> target an experimental platform (e.g. the Asterius compiler which
>>> targets WebAssembly), and previously in order to retrieve those IRs
>>> from the regular pipeline, we need to use Hooks which is somewhat
>>> hacky.
>>> Does this sound a good idea to you? If so, I can open a trac ticket
>>> and a Phab diff for this feature.
>>> Best,
>>> Shao Cheng
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list