<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">A long time ago, I’ve tried to inject plugin logic to allows some control over the driver pipeline (phase ordering) and hooking various code gen related functions.<div><br></div><div>See <a href="https://phabricator.haskell.org/D535">https://phabricator.haskell.org/D535</a></div><div><br></div><div>At that time I ran into issues that might simply not exist with plugins anymore today, but I haven’t looked.</div><div><br></div><div>The whole design wasn’t quite right and injects everything into the dynflags.  Also ghc wanted to be able to compile the plugin on the fly, but I needed the plugin to be loaded very early during the startup phase to exert enough control of the rest of the pipeline through the plugin.</div><div><br></div><div>Cheers,</div><div> Moritz</div><div><br></div><div><div id="AppleMailSignature" dir="ltr">Sent from my iPhone</div><div dir="ltr"><br>On 5 Oct 2018, at 1:52 AM, Shao, Cheng <<a href="mailto:cheng.shao@tweag.io">cheng.shao@tweag.io</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><blockquote type="cite"><span>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.</span><br></blockquote><span></span><br><span>I think setting up a new global libdir/pkgdb is beyond the scope of</span><br><span>backend plugins. The user shall implement his/her own boot script to</span><br><span>configure for the new architecture, generate relevant headers, run</span><br><span>Cabal's Setup program to launch GHC with the plugin loaded.</span><br><span></span><br><blockquote type="cite"><span>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.</span><br></blockquote><span></span><br><span>For the use case of asterius itself, indeed Hooks already fit the use</span><br><span>case for now. But since we seek to upstream our newly added features</span><br><span>in our ghc fork back to ghc hq, we should upstream those changes early</span><br><span>and make them more principled. Compared to Hooks, I prefer to move to</span><br><span>Plugins entirely since:</span><br><span></span><br><span>* Plugins are more composable, you can load multiple plugins in one</span><br><span>ghc invocation. Hooks are not.</span><br><span>* If I implement the same mechanisms in Plugins, this can be</span><br><span>beneficial to other projects. Currently, in asterius, everything works</span><br><span>via a pile of hacks upon hacks in ghc-toolkit, and it's not good for</span><br><span>reuse.</span><br><span>* The newly added backend plugins shouldn't have visible</span><br><span>correctness/performance impact if they're not used, and it's just a</span><br><span>few local modifications in the ghc codebase.</span><br><span></span><br><blockquote type="cite"><span>On Thu, Oct 4, 2018 at 3:56 PM Shao, Cheng <<a href="mailto:cheng.shao@tweag.io">cheng.shao@tweag.io</a>> wrote:</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Hi all,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I'm thinking of adding "backend plugins" in the current Plugins</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>mechanism which allows one to inspect/modify the IRs post simplifier</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>pass (STG/Cmm), similar to the recently added source plugins for HsSyn</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>IRs. This can be useful for anyone creating a custom GHC backend to</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>target an experimental platform (e.g. the Asterius compiler which</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>targets WebAssembly), and previously in order to retrieve those IRs</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>from the regular pipeline, we need to use Hooks which is somewhat</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>hacky.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Does this sound a good idea to you? If so, I can open a trac ticket</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>and a Phab diff for this feature.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Best,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Shao Cheng</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>_______________________________________________</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>ghc-devs mailing list</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a></span><br></blockquote></blockquote><span>_______________________________________________</span><br><span>ghc-devs mailing list</span><br><span><a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a></span><br><span><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a></span><br></div></blockquote></div></body></html>