osa1 (Ömer Sinan Ağacan)
User

Projects

User does not belong to any projects.

User Details

User Since
Jun 6 2014, 2:22 AM (241 w, 1 d)

Recent Activity

Yesterday

osa1 committed rGHC8c3133a6e513: Comments in stranal test declarations (authored by osa1).
Comments in stranal test declarations
Fri, Jan 18, 6:31 AM

Thu, Jan 17

osa1 committed rGHCa1e9cd6af8b4: Add test for #16197 (authored by osa1).
Add test for #16197
Thu, Jan 17, 11:51 AM
osa1 committed rGHCa34ee6154593: Refactor GHCi UI to fix #11606, #12091, #15721, #16096 (authored by osa1).
Refactor GHCi UI to fix #11606, #12091, #15721, #16096
Thu, Jan 17, 11:50 AM
osa1 committed rGHC448f0e7dd78a: Fix checkPtrInArena (authored by osa1).
Fix checkPtrInArena
Thu, Jan 17, 11:50 AM
osa1 committed rGHC19670bc397d8: Fix negative mutator time in GC stats in prof builds (authored by osa1).
Fix negative mutator time in GC stats in prof builds
Thu, Jan 17, 11:50 AM
osa1 committed rGHC74cd4ec5d2f9: Fix raiseAsync() UNDERFLOW_FRAME handling in profiling runtime (authored by osa1).
Fix raiseAsync() UNDERFLOW_FRAME handling in profiling runtime
Thu, Jan 17, 11:50 AM
osa1 committed rGHCcb2349a4233d: Documentation and refactoring in CCS related code (authored by osa1).
Documentation and refactoring in CCS related code
Thu, Jan 17, 11:50 AM

Wed, Jan 16

osa1 committed rGHC82d1a88dec21: Implement a sanity check for CCS fields in profiling builds (authored by osa1).
Implement a sanity check for CCS fields in profiling builds
Wed, Jan 16, 12:24 AM
osa1 committed rGHC2880cb9840e2: Dump Cmm with -ddump-cmm when building .cmm files (authored by osa1).
Dump Cmm with -ddump-cmm when building .cmm files
Wed, Jan 16, 12:24 AM
osa1 committed rGHC6e4e63764aaf: Minor refactoring and documentation in profiling RTS code (authored by osa1).
Minor refactoring and documentation in profiling RTS code
Wed, Jan 16, 12:24 AM

Wed, Jan 9

osa1 abandoned D5473: Refactor GHCi UI to fix #16096.

Migrated to gitlab: https://gitlab.haskell.org/ghc/ghc/merge_requests/97

Wed, Jan 9, 9:48 AM

Tue, Jan 8

osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

Where are we on this work?

Tue, Jan 8, 8:40 AM

Thu, Dec 27

osa1 updated the summary of D5473: Refactor GHCi UI to fix #16096.
Thu, Dec 27, 4:14 AM
osa1 updated the diff for D5473: Refactor GHCi UI to fix #16096.
  • Remove duplication
Thu, Dec 27, 4:13 AM
osa1 updated the summary of D5473: Refactor GHCi UI to fix #16096.
Thu, Dec 27, 3:44 AM
osa1 updated the diff for D5473: Refactor GHCi UI to fix #16096.
  • Add test
Thu, Dec 27, 3:43 AM
osa1 updated the summary of D5473: Refactor GHCi UI to fix #16096.
Thu, Dec 27, 3:28 AM
osa1 updated the test plan for D5473: Refactor GHCi UI to fix #16096.
Thu, Dec 27, 3:27 AM
osa1 updated the diff for D5473: Refactor GHCi UI to fix #16096.
  • Update test output
Thu, Dec 27, 3:27 AM
osa1 added inline comments to D5473: Refactor GHCi UI to fix #16096.
Thu, Dec 27, 3:02 AM
osa1 updated the summary of D5473: Refactor GHCi UI to fix #16096.
Thu, Dec 27, 3:01 AM
osa1 updated the diff for D5473: Refactor GHCi UI to fix #16096.
  • Enable a broken test
Thu, Dec 27, 3:00 AM
osa1 updated the diff for D5473: Refactor GHCi UI to fix #16096.
  • Fix a bug, simplify things
Thu, Dec 27, 2:55 AM
osa1 added a comment to D5473: Refactor GHCi UI to fix #16096.

This broke one test:

Thu, Dec 27, 2:10 AM
osa1 added a comment to D4647: RFC: Continuation arguments.

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.

Thu, Dec 27, 12:47 AM

Wed, Dec 26

osa1 added a comment to D4647: RFC: Continuation arguments.

@alexbiehl will you be working on this? Do you mind if I finish the implementation?

Wed, Dec 26, 11:55 PM
osa1 planned changes to D5473: Refactor GHCi UI to fix #16096.

I left some TODOs in the description.

Wed, Dec 26, 8:31 AM
osa1 created D5473: Refactor GHCi UI to fix #16096.
Wed, Dec 26, 8:30 AM

Tue, Dec 25

osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

I added some comments about the refactoring here: https://github.com/osa1/ghc/commit/f377f048fef88d8f01414d34a913ed18798a7ba6#commitcomment-31778391

Tue, Dec 25, 9:07 PM
osa1 added a comment to D5470: Disable timer-based context switches.

Should we also do this for all the other benchmarks?

Tue, Dec 25, 7:25 AM
osa1 accepted D5469: Compare results of compress by hashing.

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).

Tue, Dec 25, 7:21 AM
osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.
In D5432#151106, @osa1 wrote:

So all this work is wasted. As I said in this comment https://phabricator.haskell.org/D5432#150851, I propose getting rid of the CafInfo field of IdLabel entirely. Did you try that?

I started doing that, but I'm not sure how to implement cafAnal, more specifically cafTransfers needs to get CAFFY labels in a CmmBlock. Any ideas on this?

Tue, Dec 25, 12:39 AM

Mon, Dec 24

osa1 updated the summary of D5432: Do Caf analysis right before codegen, fix #9718.
Mon, Dec 24, 11:43 PM
osa1 updated the diff for D5432: Do Caf analysis right before codegen, fix #9718.
  • Rebase, enable panic in StgCafAnal again
Mon, Dec 24, 11:40 PM
osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

So all this work is wasted. As I said in this comment https://phabricator.haskell.org/D5432#150851, I propose getting rid of the CafInfo field of IdLabel entirely. Did you try that?

Mon, Dec 24, 10:03 AM
osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

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.

Mon, Dec 24, 6:19 AM
osa1 committed rGHC8a0fca09565d: Simplify Core output with -dsuppress-type-signatures (authored by osa1).
Simplify Core output with -dsuppress-type-signatures
Mon, Dec 24, 6:03 AM
osa1 closed D5472: Simplify Core output with -dsuppress-type-signatures.
Mon, Dec 24, 6:03 AM
osa1 updated the diff for D5472: Simplify Core output with -dsuppress-type-signatures.
  • Update test output
Mon, Dec 24, 6:01 AM
osa1 added a comment to D5469: Compare results of compress by hashing.
In D5469#151068, @osa1 wrote:

I'm confused

Invoking compress during boot to generate the stdout file doesn't work,
because at that point the dependency file for building compress might not have
been created yet, resulting in make boot failures.

Why would you invoke compress during boot? Isn't compress a benchmark that
needs to be run _after_ boot?

The idea was we don't want the result in the repo as it's a sizeable binary file that doesn't compress well.

So we either have to shrink it (this patch) or generate it during boot (state before this patch).
The easiest way to generate the output file during boot is by using compress itself, so that's what I did initially.
In hindsight it was a bad solution for more than one reason, hence why sgraf is changing it.

Mon, Dec 24, 5:06 AM
osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

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.

Mon, Dec 24, 2:31 AM
osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

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

Mon, Dec 24, 1:16 AM
osa1 updated the summary of D5432: Do Caf analysis right before codegen, fix #9718.
Mon, Dec 24, 12:41 AM

Sun, Dec 23

osa1 added a comment to D5469: Compare results of compress by hashing.

I'm confused

Sun, Dec 23, 11:26 PM

Sat, Dec 22

osa1 updated the summary of D5432: Do Caf analysis right before codegen, fix #9718.
Sat, Dec 22, 1:32 AM
osa1 planned changes to D5472: Simplify Core output with -dsuppress-type-signatures.
Sat, Dec 22, 1:26 AM
osa1 added a comment to D5472: Simplify Core output with -dsuppress-type-signatures.

I need to rebase this and update expected output of Trac #16038 before merging (I pushed the test just now).

Sat, Dec 22, 1:25 AM
osa1 committed rGHC8adef36cb16b: Add test for #16038 (authored by osa1).
Add test for #16038
Sat, Dec 22, 1:22 AM
osa1 created D5472: Simplify Core output with -dsuppress-type-signatures.
Sat, Dec 22, 1:09 AM

Fri, Dec 21

osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

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:

Fri, Dec 21, 9:21 AM
osa1 updated the diff for D5432: Do Caf analysis right before codegen, fix #9718.
  • Remove outdated comment
Fri, Dec 21, 8:53 AM
osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

OK, finished reading the comments. @simonpj

Fri, Dec 21, 5:30 AM
osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.
In D5432#150882, @osa1 wrote:

I might be missing something, but how does that prevent us from accidentally using the CafInfo from the occurrence Id?

@simonpj @simonmar what do you think about making IdInfo.cafInfo a Maybe CafInfo instead of CafInfo? That way we can leave caf info of non-imported ids Nothing (initially all ids have Nothing as caf info), and idCafInfo can panic instead of returning the default value when that happens.

We can later do the same thing for arity.

Fri, Dec 21, 5:12 AM
osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

I might be missing something, but how does that prevent us from accidentally using the CafInfo from the occurrence Id?

Fri, Dec 21, 4:45 AM
osa1 updated the summary of D5432: Do Caf analysis right before codegen, fix #9718.
Fri, Dec 21, 3:23 AM
osa1 updated the diff for D5432: Do Caf analysis right before codegen, fix #9718.
  • Update CafInfos in HomeModInfo/ModDetails/TypeEnv
Fri, Dec 21, 3:19 AM

Thu, Dec 20

osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

@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?

Thu, Dec 20, 11:47 PM
osa1 updated the summary of D5432: Do Caf analysis right before codegen, fix #9718.
Thu, Dec 20, 11:43 PM

Dec 20 2018

osa1 updated the summary of D5432: Do Caf analysis right before codegen, fix #9718.
Dec 20 2018, 7:00 AM
osa1 updated the summary of D5432: Do Caf analysis right before codegen, fix #9718.
Dec 20 2018, 6:58 AM
osa1 committed rGHC557178619aa2: Remove an old OPTIONS_GHC (authored by osa1).
Remove an old OPTIONS_GHC
Dec 20 2018, 6:39 AM
osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

PS: One other thing to check.

In GHCi, or --make, we create a ModDetails for subsequent modules to use. We carefully ensure that every Id has the right IdInfo. I think this is done in TidyPgm.

We must make sure that the TypeEnv in this persistent ModDetails has the final CafInfo in it!

Dec 20 2018, 6:19 AM
osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

Hang on. updateStgCafInfos puts CAF info into the IdInfo of a binder. But who looks at that info? I guess:

  1. We use it when creating the interface file so importing modules see correct CAF info
  2. We use it when creating SRTs

    I think you have (1) well under control. Presumably after CAF analysis you pass a finite map (Name -> CAFInfo) to the interface-file-modification stuff?
Dec 20 2018, 6:04 AM
osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

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...

Dec 20 2018, 5:28 AM
osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

STGs and Cmms are identical (including CafInfos) so compress2 residency should also be noise.

Dec 20 2018, 2:37 AM
osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

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.

Dec 20 2018, 2:27 AM
osa1 updated the summary of D5432: Do Caf analysis right before codegen, fix #9718.
Dec 20 2018, 2:26 AM
osa1 updated the diff for D5432: Do Caf analysis right before codegen, fix #9718.
  • Update STG top-level binder CafInfos before codegen
Dec 20 2018, 2:24 AM
osa1 updated the summary of D5432: Do Caf analysis right before codegen, fix #9718.
Dec 20 2018, 2:22 AM
osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

Yep! That fixed it for bernouilli. I'll now boot GHC again and run nofib again and update numbers.

Dec 20 2018, 12:47 AM
osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

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.

Dec 20 2018, 12:13 AM
osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

Hmm, I think this is because of a bug. The extra SRT entry is for this closure: lvl1_r6SP_closure. In STG:

Dec 20 2018, 12:09 AM

Dec 19 2018

osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

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).

Dec 19 2018, 11:59 PM
osa1 updated the diff for D5432: Do Caf analysis right before codegen, fix #9718.
  • Print iface CafInfos as before, to make comparing iface files easier
Dec 19 2018, 11:24 PM
osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

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).

Dec 19 2018, 7:28 AM
osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

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 19 2018, 6:28 AM
osa1 updated the summary of D5432: Do Caf analysis right before codegen, fix #9718.
Dec 19 2018, 6:27 AM

Dec 18 2018

osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.
In D5432#150596, @osa1 wrote:

As far as I can tell, in this diff we calculate the fingerprints as normal in mkIface but then update the CafInfo later. Isn't this wrong? The fingerprints need to take into account the CafInfo, so we have to defer computing the fingerprints until after the CafInfo is added.

Currently we generate interface files only once so this should be fixed. (in the revision you reviewed I was generating interfaces with conservative CafInfos and then updating with precise CafInfos, without updating fingerprints)

Could you explain a bit more how this happens? It looks like you still have the function updateIfaceCafInfos :: ModIface -> NameEnv (a, CafInfo) -> ModIface, which is unsafe: it doesn't update the fingerprints, so the ModIface being returned from this function is wrong.

Dec 18 2018, 9:47 AM
osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

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.

Dec 18 2018, 8:10 AM
osa1 updated the summary of D5432: Do Caf analysis right before codegen, fix #9718.
Dec 18 2018, 8:09 AM
osa1 updated the summary of D5432: Do Caf analysis right before codegen, fix #9718.
Dec 18 2018, 8:08 AM
osa1 updated the summary of D5432: Do Caf analysis right before codegen, fix #9718.
Dec 18 2018, 6:45 AM
osa1 updated the diff for D5432: Do Caf analysis right before codegen, fix #9718.
  • Remove old TODO
  • Add a note
Dec 18 2018, 3:53 AM
osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

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 18 2018, 2:40 AM
osa1 updated the summary of D5432: Do Caf analysis right before codegen, fix #9718.
Dec 18 2018, 2:39 AM

Dec 17 2018

osa1 updated the diff for D5432: Do Caf analysis right before codegen, fix #9718.
  • Introduce tcLocalIdInfo
  • Move dep analysis to StgCafAnal
Dec 17 2018, 11:59 PM
osa1 added a comment to D5432: Do Caf analysis right before codegen, fix #9718.

As far as I can tell, in this diff we calculate the fingerprints as normal in mkIface but then update the CafInfo later. Isn't this wrong? The fingerprints need to take into account the CafInfo, so we have to defer computing the fingerprints until after the CafInfo is added.

Dec 17 2018, 11:08 PM
osa1 updated the summary of D5432: Do Caf analysis right before codegen, fix #9718.
Dec 17 2018, 11:01 PM
osa1 updated the diff for D5432: Do Caf analysis right before codegen, fix #9718.
  • Fix -dynamic-too with with --make/backpack
Dec 17 2018, 11:22 AM

Dec 14 2018

osa1 updated the summary of D5432: Do Caf analysis right before codegen, fix #9718.
Dec 14 2018, 8:26 AM
osa1 updated the diff for D5432: Do Caf analysis right before codegen, fix #9718.
  • Update test outputs
  • Simplify iface generation before codegen
Dec 14 2018, 8:25 AM

Dec 13 2018

osa1 committed rGHCf583ccfe6408: Update -F RTS help: (authored by osa1).
Update -F RTS help:
Dec 13 2018, 10:31 PM
osa1 closed D5445: Update -F RTS help:.
Dec 13 2018, 10:31 PM
osa1 updated the summary of D5432: Do Caf analysis right before codegen, fix #9718.
Dec 13 2018, 4:23 AM
osa1 updated the diff for D5432: Do Caf analysis right before codegen, fix #9718.
  • Remove IfaceIdInfo type
  • Simplify iface updates by moving caf info to its own field
Dec 13 2018, 4:22 AM

Dec 12 2018

osa1 updated the diff for D5445: Update -F RTS help:.
  • Add one more missing comma
Dec 12 2018, 11:58 PM
osa1 added inline comments to D5428: Add +RTS -F to the --help output.
Dec 12 2018, 11:33 PM
osa1 created D5445: Update -F RTS help:.
Dec 12 2018, 11:33 PM
osa1 added inline comments to D5428: Add +RTS -F to the --help output.
Dec 12 2018, 11:31 PM
osa1 committed rGHCf899b3892a8c: Show recursive Stg bindings in Rec {} blocks (authored by osa1).
Show recursive Stg bindings in Rec {} blocks
Dec 12 2018, 10:56 PM