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

[Shao, Cheng]

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

I think setting up a new global libdir/pkgdb is beyond the scope of
backend plugins. The user shall implement his/her own boot script to
configure for the new architecture, generate relevant headers, run
Cabal's Setup program to launch GHC with the plugin loaded.

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

For the use case of asterius itself, indeed Hooks already fit the use
case for now. But since we seek to upstream our newly added features
in our ghc fork back to ghc hq, we should upstream those changes early
and make them more principled. Compared to Hooks, I prefer to move to
Plugins entirely since:

* Plugins are more composable, you can load multiple plugins in one
ghc invocation. Hooks are not.
* If I implement the same mechanisms in Plugins, this can be
beneficial to other projects. Currently, in asterius, everything works
via a pile of hacks upon hacks in ghc-toolkit, and it's not good for
reuse.
* The newly added backend plugins shouldn't have visible
correctness/performance impact if they're not used, and it's just a
few local modifications in the ghc codebase.

> 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
>> 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 haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs