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

Luite Stegeman stegeman at
Thu Oct 4 16:33:43 UTC 2018

I think it sounds like a potentially good idea in general, but I agree with
Ben and Matthew here that a more concrete plan of intended use is needed.

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

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.

I don't think it's a problem if a hook exists for some time, and at some
point it's superseded by a more general plugin mechanism. Especially with
the GHC 6 month release cycle there's not much need for future proofing.


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list