Re: Phabricator workflow vs. GitHub
There are some things in these argumentations that I don't get. When you have a stack of commits on top of master, like: * C | * B | * A | * master What do you use as base for `arc diff` for each of them? If B depends on A (the patch expressed by B doesn't apply if A was applied first), do you still use master as a base for B, or do you use Phabricator's feature to have diffs depend on other diffs? ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Does it sound a good idea to implement "backend plugins"?
> 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 manipulation of a Hooks via a Plugin seems overkill in this case, and even if one can do so, it still doesn't lead to the backend IR types; one would need to use runPhaseHook and modify the behavior after a CgGuts is generated, which unfortunately leads to quite some boilerplate code. > At that time I ran into issues that might simply not exist with plugins > anymore today, but I haven’t looked. Interesting. I'll make sure to consult you in case I'm bitten by some hidden issues when I actually implement it :) > 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. Well, in the case of backend plugins, it isn't supposed to be a home plugin to be compiled and used on the fly. A typical use case would be compiling/installing the plugin to a standalone pkgdb, then used to compile other packages. > > On 5 Oct 2018, at 1:52 AM, Shao, Cheng wrote: > > 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 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@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Does it sound a good idea to implement "backend plugins"?
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, but I haven’t looked. 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. Cheers, Moritz Sent from my iPhone On 5 Oct 2018, at 1:52 AM, Shao, Cheng wrote: >> 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 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@haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Does it sound a good idea to implement "backend plugins"?
> 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 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@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Does it sound a good idea to implement "backend plugins"?
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 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@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Does it sound a good idea to implement "backend plugins"?
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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: nofib oldest GHC to support?
Typically I never remove any support for older compilers in nofib and the nofib-analyze tool, I just add support for new things. I realise we don't continuously test any of those old versions and thus they can bitrot, but in my experience so far it doesn't happen very often, and it's sometimes really useful to be able to use older versions. Why did it break with 7.10.3? Can that be fixed? I guess we could remove the Gofer support though :) In the list of regrexes you pointed to, don't you just need to add one more to support the new format? It would be nice if those regexes had comments to explain which version they were added for, I guess we could start doing that from now on. Cheers Simon On Mon, 1 Oct 2018 at 09:05, Ömer Sinan Ağacan wrote: > We currently claim to support GOFER and GHC 4.02! Surely we can drop some > of > those support. > > I just tried booting nofib with GHC 7.10.3 and it failed. We don't even > support > 7.10.3, but we still have code to support ... 4.02! > > The desire to cleanup is not because removing code is fun, it's because it > makes it easier to maintain. Currently I need to parse another variant of > `+RTS > -t` output, and I have to deal with this mess for it: > > > https://github.com/ghc/nofib/blob/a80baacfc29cc2e7ed50e94f3cd2648d11b1d7d5/nofib-analyse/Slurp.hs#L153-L207 > > (note that all of these need to be updated to add one more field) > > If we decide on what versions to support we could remove most of those (I > doubt > `+RTS -t` output changes too much, so maybe we can even remove all but > one). > > There are also other code with CPP macros for GOFER etc. > > I suggest supporting HEAD + 3 major releases. In this plan currently we > should > be able to run nofib with GHC HEAD, 8.6, 8.4, and 8.2. Then setting up a > CI to > test nofib with these configurations should be trivial (except for GHC HEAD > maybe, I don't know if we're publishing GHC HEAD bindists for CI servers to > use). > > Ömer > Joachim Breitner , 1 Eki 2018 Pzt, 03:33 > tarihinde şunu yazdı: > > > > Hi, > > > > there is no policy that I am aware of, but being able to run nofib on > > old (or even ancient) versions of GHC is likely to make someone happy > > in the future, so I’d say that the (valid!) desire to cleanup is not a > > good reason to drop support – only if it would require unreasonable > > efforts should we drop old versions there. > > > > Cheers, > > Joachim > > > > Am Sonntag, den 30.09.2018, 14:18 +0300 schrieb Ömer Sinan Ağacan: > > > Do we have a policy on the oldest GHC to support in nofib? I'm > currently doing > > > some hacking on nofib to parse some new info printed by a modified > GHC, and I > > > think we can do a lot of cleaning (at the very least remove some > regexes and > > > parsers) if we decide on which GHCs to support. > > > > > > I checked the README and RunningNoFib wiki page but couldn't see > anything > > > relevant. > > > > > > Thanks > > > > > > Ömer > > > ___ > > > ghc-devs mailing list > > > ghc-devs@haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- > > Joachim Breitner > > m...@joachim-breitner.de > > http://www.joachim-breitner.de/ > > > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
