Yes, we definely want these. Are you wanting each of these submitted as a separate differential *in order*? Or do you want a more complex mix-and-match? Also, are there any commits you think should be squashed?
On Friday, February 17, 2017 4:41:33 PM EST Simon Peyton Jones via ghc-devs wrote: > Ben, David, Reid > I have been working for months (on and off, mostly off, but very ON for the > last week or two) on a very simple idea: the simplifier should inline > things even in the "gentle" phase. It seems so simple. And it is: the key > patch is tiny. > But it stressed corners of the optimiser that were not stressed before; and > digging into it showed opportunities I did not know about before. So I > have ended up a with a whole series of patches, which are on > wip/spj-early-inline branch > > 7f14d15c0e5fc2c9a81db3d0f0b01d85857b1d87 Error message wibbles accumulated > from the preceding patches > > 0499c65d9fa45e7879e1e1264fdaa15274adcba6 Improve SetLevels for join points > > 3b2fc0827ff6cafa34836c2d9dc710b628c990b6 Change -ddump-tc-trace output in > TcErrors, slightly > > 9ffdf62b0ca72c4f35579f9d6f31a9beebf23025 Improve pretty-printing of types > > 3f346eac06399a79adf48425018ee949cee245bf Add VarSet.anyDVarSet, allDVarSet > > 912e71eb3b4ec91e805ecf2236d1033e55e2933a The Early Inline Patch > > 7188cd13f8e54efa764d52ca016b87b3669b29f5 Small changes to expression sizing > in CoreUnfold > > bfc6fa3f377d11bdfcdbf82b65bf2f39cb00b90c Fix SetLevels for makeStaticPtr > > 8b1cfea089faacb5b95ffcc3511e05faeabb8076 Extend CSE to handle recursive > bindings > > 50411995641802568bb27c867afe804f91e0524c Combine identical case alterantives > in CSE > > 2e077ccc736a0b2a622b7f42b7929966bddb4ded Inline data constructor wrappers in > phase 2 only > > b868de53dd19f639c1070089ecff21948ff33e0d Make Specialise work with casts > > c767ae5f04a09ef71dcb8f67a17225a52c2cc5d2 Stop uniques ending up in SPEC rule > names > > b49ed1f0102f93ca7f62632c436b41bd240b501f Occurrence-analyse the result of > rule firings > > 607a735dfb99bb8f0edf466ccb01e732218c42ec Add -fspec-constr-keen > > 67a0c1872c0515f1f12ea68097a84e02da92f45b Refactor floating of bindings > (fiBind) > > e90f4d7c6d3003039fa1647a3da3dafcaa75527b More tracing in SpecConstr > > > Much to my surprise, we get some jolly nice improvements in compiler perf: > > 3% perf/compiler/T5837.run T5837 [stat too good] (normal) > > 7% perf/compiler/parsing001.run parsing001 [stat too good] (normal) > > 9% perf/compiler/T12234.run T12234 [stat too good] (optasm) > > 35% perf/compiler/T9020.run T9020 [stat too good] (optasm) > > 9% perf/compiler/T3064.run T3064 [stat too good] (normal) > > 13% perf/compiler/T9961.run T9961 [stat too good] (normal) > > 20% perf/compiler/T13056.run T13056 [stat too good] (optasm) > > 5% perf/compiler/T9872d.run T9872d [stat too good] (normal) > > 5% perf/compiler/T9872c.run T9872c [stat too good] (normal) > > 5% perf/compiler/T9872b.run T9872b [stat too good] (normal) > > 7% perf/compiler/T9872a.run T9872a [stat too good] (normal) > > 5% perf/compiler/T783.run T783 [stat too good] (normal) > > 35% perf/compiler/T12227.run T12227 [stat too good] (normal) > > 20% perf/compiler/T1969.run T1969 [stat too good] (normal) > > 5% perf/should_run/lazy-bs-alloc.run lazy-bs-alloc [stat too good] > (normal) > > 5% perf/compiler/T12707.run T12707 [stat too good] (normal) > > > > 4% perf/compiler/T3294.run T3294 [stat too good] (normal) > > 1.5% perf/space_leaks/T4029.run T4029 [stat too good] (ghci) > > So what is left? I have sunk so much time into this and am still not QUITE > out of the woods. I was left with > > Unexpected failures: > > codeGen/should_compile/debug.run debug [bad stdout] (normal) > > concurrent/should_run/T4030.run T4030 [bad exit code] > (normal) I'm re-validating having pulled from HEAD, but I THINK that's all. > Now > > * I don't know how to Phab these individually > > * I have not sweated through which patch is responsible for which > perf improvments. Maybe Gipeda can tell? > > * I have not put each error message change with the correct patch. > I don't know how much that matters. So this is to say: anything you guys > can do to help get this actually Done would be really helpful. I'm out of > time till Monday at least. It would be great to collect those performance > improvements! > Thanks! > Simon _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs