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
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