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 <[email protected]> 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 > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
