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 practice. 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. Luite On Thu, Oct 4, 2018 at 3:56 PM Shao, Cheng <cheng.shao@tweag.io> 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs