- User Since
- Jun 8 2014, 1:59 AM (231 w, 2 d)
In this patch, I have copied the relevant bits from the GCC source code, and modified it to fit the GHC conventions.
But, we must make sure that we don't violate the GPL.
Fri, Nov 9
If there's a better fix, please abandon this diff.
I think we'll need to do something much more general than this in the future when we have a mixture of Int8#, Int16#, etc. fields that need to be packed into words. Happy to go with this for now though.
Mon, Nov 5
Trac Trac #15847: We don't support loading non-PIC .o on i386, this is why I noticed this issue
Fri, Nov 2
I'm not sure I understand the problem here. Why is there a missing symbol error?
Sure, seems reasonable.
Fri, Oct 26
Thanks for adding the test!
Wed, Oct 24
This is great. It could be even better if
- We had your benchmark in the test suite, perhaps testsuite/tests/perf? We can use small parameters so it doesn't run for long.
- We point to the benchmark from comments in the code, so that others can use it when making future changes.
Fri, Oct 19
A bit more review
Will this work with g++ with no flags? If not, what else would be needed?
Thu, Oct 18
btw, use #1234 for ticket references in Phabricator markup.
I think we could remove this, it's a very small code-size optimisation and would require a fair bit more work to implement, not at all clear that it's worth it. I commented more on the ticket.
Mon, Oct 15
- We should build these at installation time, so they don't have to go into the binary distribution (the same goes for the vanilla way` libHSfoo.o` files)
- This also needs to be done in Hadrian
Oct 10 2018
This looks OK.
Oct 9 2018
For Maybe [String] I would just pprDebug $ text (show x).
Oct 8 2018
Wow! Some questions below.
It's not obvious to me that we should render a String like this in Outputable, after all we don't render a FastString with double quotes, and we don't render a Char with single quotes. Outputable is not intended to produce Haskell concrete syntax, it's mainly for pretty-printing the various internal compiler data structures.
Oct 7 2018
Looks good. Was that with the libraries recompiled too?
Oct 6 2018
I'd be really interested to see what effect this has on performance and code size too.
Oct 4 2018
nofib results below
@osa1 We save the old info pointer when entering a CAF: https://phabricator.haskell.org/diffusion/GHC/browse/master/rts%2Fsm%2FStorage.c$406
Looks good to go, provided it passes validate.
Oct 3 2018
Oct 1 2018
Another option might be to keep top-level strings updatable, but make the GC revert the CAF. That way we would get some of the sharing back.
Sep 29 2018
Sep 28 2018
Sep 27 2018
Builds are failing, but looks unrelated.
Sep 26 2018
Sep 25 2018
Does that include the ghc package?
Great! This should make ghc -fexternal-interpreter -prof a lot faster to start up, and some of the tests will run faster.
Sep 24 2018
Sep 21 2018
Sep 20 2018
Looks great, code is cleaner too! Thanks for doing this.
I would make a version of overwritingClosure that takes the size parameter and call that. It looks like we're missing out on the call to LDV_recordDead() that overwritingClosure also does.
Can we just turn off -Waggregate-return instead? It's not useful, there's absolutely nothing wrong with returning structs from functions.
Sep 18 2018
Thanks for testing @osa1 and for the code review, and sorry (once again) for the collateral damage caused by the SRT rework!
Sep 15 2018
Ok cool. We better tell @ekmett that stable-maps is not type-safe any more :)
Sep 14 2018
@bgamari I see you reverted the SRT patches. So we're not going with this?
Sep 13 2018
nofib results (ignore the runtime results which are unreliable on my laptop, this was just to confirm there was no increase in binary sizes).
Also fix this bug in the case of SRTs for recursive groups. See (yet
more) comments for details.
Sep 12 2018
Yeah, it seems this doesn't completely fix the problem. Will figure out the right fix tomorrow.
@bgamari this validated locally but there's a perf test failure in Harbourmaster. Also I see trunk has been failing for quite a while, although the most recent few failures look like a different perf test. Yuck :(
Sep 11 2018
Sep 10 2018
Ok, could you also remove the hack in rts/package.conf.in since that's no longer necessary?
As a general point, if dtrace is to be a first-class supported feature then it needs to have tests and documentation.
Yeah, I find this useful too and often enable it in my build.mk.
Sep 7 2018
I think we can go ahead with this. @bgamari would you like to push it?
I presume this is because we can't use the same method that the old build system uses? https://phabricator.haskell.org/diffusion/GHC/browse/master/rts%2Fpackage.conf.in$177-181
Sep 6 2018
It would be nicer to put unrelated changes in separate commits, but OK.
If this adds a big compile time overhead, perhaps it should be enabled for -O2 only?
@lelf I'm not sure if you're raising an exception to this patch or not. If you are, could you explain exactly what problem it could introduce? @last_g says the patch has no effect on dtrace, do you disagree?
Good catch! Let's get this merged into the stable branch too.