- User Since
- Jun 6 2014, 2:22 AM (249 w, 6 d)
Tue, Mar 12
Wed, Mar 6
Mon, Mar 4
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:
Dec 19 2018
Hmm this is really weird. I'm looking at bernoulli to see what's causing the size difference. Core and Stg files and iface dumps (-show-iface) are identical (CafInfos are printed in Stg dumps and those are identical too), but there are differences in Cmm and final binaries have different size (3077896 originally, 3086024 with this patch).
- Print iface CafInfos as before, to make comparing iface files easier
I also need to think more about the fingerprinting issue -- if I simply call addFingerprints before writing the interface file I break recomp005 (the progress message says A changed instead of D changed when rebuilding E.hs).
Sign unfortunately I really did make a mistake last time and confused GHC trees. I now updated nofib numbers, binaries are larger now. I'll try to see why. As discussed at the meeting I tried running nofib with +RTS -F1 which made the residencies identical.
Dec 18 2018
Sorry for the noise.. I thought I did a mistake when analysing nofib results, but it turns out there were no mistakes. I also checked linear. For some reason we make things more caffy in that program, but I don't know why yet. I'll now look at maillist, perhaps that's easier to explain.
- Remove old TODO
- Add a note
See nofib results in the description. I'll try to see what caused TotalMem regressions in linear and maillist. (I suspect this is because we float more things out now and trade residency for allocation, but I'll check)
Dec 17 2018
- Introduce tcLocalIdInfo
- Move dep analysis to StgCafAnal
- Fix -dynamic-too with with --make/backpack
Dec 14 2018
- Update test outputs
- Simplify iface generation before codegen