Does it sound a good idea to implement "backend plugins"?
stegeman at gmail.com
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 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
> Does this sound a good idea to you? If so, I can open a trac ticket
> and a Phab diff for this feature.
> Shao Cheng
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs