- User Since
- Jun 8 2014, 1:59 AM (206 w, 6 d)
But SRTs are writable - they have a static link field at the end which is modified by the GC. So I'm confused, how can this work? We should probably fix the declaration to remove the const instead.
Thu, May 24
Had a chat with @last_g about this in person today. The overall goal is good and this will improve GHC's interaction with perf. Let's figure out the concrete steps to get this in:
Wed, May 23
@Phyx thanks so much for this! I'll go ahead and push.
Build error though:
Thanks for doing this!
Tue, May 22
Is it possible to make a test for this?
Mon, May 21
We ought to check what LLVM does and that whatever we do here doesn't break the LLVM backend.
Sun, May 20
Partial review - this looks really cool! Definitely needs polishing + comments though.
Thu, May 17
(warning: this is a really old partial review that I only just discovered I forgot to submit)
retrying; database failure the first time
This seems like quite an elaborate fix for an overflow problem. Why did the overflow occur in the first place, shouldn't the time remaining be less than maxBound?
Passes the profiling tests here
D4707, testing now.
Thanks, will take a look.
Thanks! Sorry for the breakage. (could we make Harbourmaster any faster? The iteration time of >24 hours means it's pretty painful to get to a clean validate on all platforms)
Wed, May 16
Yes, though https://phabricator.haskell.org/rGHC2b0918c9834be1873728176e4944bec26271234a is responsible for the info table compression.
I pushed this but forgot that there were still comments to address... sorry about that, will address them in a follow up.
Tue, May 15
Mon, May 14
Sun, May 13
update haddock perf stats
The reason that validate --slow might not be exactly the same as what we see in CI is that validate --slow enables DEBUG for stage 2, whereas we don't do that in CI because we're building binaries for distribution and DEBUG would make them slower. The warning messages you're seeing in the Cabal tests are only emitted when the compiler is built with DEBUG. (apologies if this was pointed out elsewhere, I haven't read all the surrounding tickets here)
add a hack to fix backpack
Thu, May 10
Sorry! Of course it broke things because I haven't committed the fix for these yet. D'oh. I'll back it out.
LGTM, thanks for straightening this out. Should we make a ticket for the issue with the regression test?
The backpack failures are from D4659 (I stacked this diff on top of that one in my tree)
The only way to decide whether this is a good idea is to get data (and plenty of it). nofib on multiple different hardware types, the nofib/parallel suite too.
Wed, May 9
also update rts.cabal.in
I wanted to check the impact on compiler perf, so full nofib results: P180 (ignore the runtime results, I think my laptop was busy doing other things during one of the runs)
- accept new stats result for T13701
Tue, May 8
Just a few nits
I suppose I could add these to the list of -u symbols we already have in package.conf.in.
I have mixed feelings about this.
Ooh, I learned something today.
(Personally I think entering an unused sum field should be a panic rather than an exception)
Sat, May 5
Fri, May 4
Hmm, I'm not keen on bumping binary sizes by nearly 1%, given that this change is unforced.
Thu, May 3
Sure, let's do it.
update test output
LGTM, I'll let @bgamari sign off on it.