> 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.
>
> See https://phabricator.haskell.org/D535
Cool! I haven't thoroughly read the history of that diff, but allowing
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.
See https://phabricator.haskell.org/D535
At that time I ran into issues that might simply not exist with plugins anymore
today,
> 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
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
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
