- User Since
- Jun 6 2014, 2:22 AM (259 w, 17 h)
Wed, May 8
Fri, May 3
Thu, Apr 25
Apr 11 2019
Apr 8 2019
Apr 2 2019
Mar 21 2019
Mar 12 2019
Mar 6 2019
Mar 4 2019
Jan 18 2019
Jan 17 2019
Jan 16 2019
Jan 9 2019
Migrated to gitlab: https://gitlab.haskell.org/ghc/ghc/merge_requests/97
Jan 8 2019
Where are we on this work?
Dec 27 2018
- Remove duplication
- Update test output
- Enable a broken test
- Fix a bug, simplify things
This broke one test:
Thanks! I don't know what's the problem with this diff yet, and I'll be working on Phab:D4110 first, but if time permits we want to implement this too. If this diff is hopeless I may implement it differently in another diff, otherwise I'll be updating this diff.
Dec 26 2018
@alexbiehl will you be working on this? Do you mind if I finish the implementation?
I left some TODOs in the description.
Dec 25 2018
I added some comments about the refactoring here: https://github.com/osa1/ghc/commit/f377f048fef88d8f01414d34a913ed18798a7ba6#commitcomment-31778391
Should we also do this for all the other benchmarks?
Once the binary is in the repo this won't buy us much, but I guess this helps when doing shallow clone (which I never do, but perhaps others do).
Dec 24 2018
- Rebase, enable panic in StgCafAnal again
Hmm, I guess that makes sense, but I need to think more about this (I still don't understand Cmm generation too well ..). I'll try removing CafInfo from IdLabel and see how it goes. In the meantime, here's what I've got so far: https://github.com/osa1/ghc/commit/f377f048fef88d8f01414d34a913ed18798a7ba6 This makes cafInfo field Maybe, then initializes it as Nothing. The failures are as reported in my previous comments.
- Update test output
sat_sGr in the same binding is also causing problems, because we call mkClosureInfoTableLabel on it, which calls idCafInfo. The CafInfo is again passed to mkInfoTableLabel so this is quite similar to the example above.
I started doing the refactoring. I currently have cafInfo :: Maybe CafInfo (instead of putting error in the field, becuase this version makes it easier to debug as I can get call stacks by adding HasCallStack to idCafInfo and call sites), and I realized that this comment
Dec 23 2018
Dec 22 2018
I need to rebase this and update expected output of Trac #16038 before merging (I pushed the test just now).
Dec 21 2018
I started implementing this. There are some use sites of vanillaIdInfo that may still need MayHaveCafRefs as CafInfo so I have to review all use sites first. Here's the list of all uses of vanillaIdInfo, with whether they should have erroring CafInfo or not after the refactoring:
- Remove outdated comment
OK, finished reading the comments. @simonpj
I might be missing something, but how does that prevent us from accidentally using the CafInfo from the occurrence Id?
- Update CafInfos in HomeModInfo/ModDetails/TypeEnv
Dec 20 2018
@simonpj one thing I realized is because we don't generate Stg when generating bytecode we can't do CafInfo analysis for interpreted modules, so we can't update ModDetails/HomeModInfo of interpreted modules with CafInfos. Do you think this is a problem?
Hmm, I run it two more times, and I still get +8.3% TotalMem. However in one of the runs I also got -0.2% allocations. That's weird given that we generate identical Cmms...
STGs and Cmms are identical (including CafInfos) so compress2 residency should also be noise.
Great, binaries are 0.1% smaller now. I added one more TODO item for the implementation. There's still one outlier in residency which is compress2. I'll try to see if this is again bad sampling or an actual
change in residency.
- Update STG top-level binder CafInfos before codegen
Yep! That fixed it for bernouilli. I'll now boot GHC again and run nofib again and update numbers.
Hmm I think this may be because I never update IdInfos in STG (I generate a map from Ids to CafInfo which is used to update the iface), and I think IdInfos are somehow used during SRT generation. I should check if this is the case, and update IdInfos.
Hmm, I think this is because of a bug. The extra SRT entry is for this closure: lvl1_r6SP_closure. In STG: