- User Since
- Jun 8 2014, 1:59 AM (146 w, 2 d)
Mon, Mar 20
The right way to do this is to add new MachOps and implement them for all the native backends and LLVM. However, that's a lot of work and the Cmm versions are a reasonable second-best. (let's avoid the ByteArray# versions if we can)
Fri, Mar 17
IdInfo is already lazy, BTW. Maybe this should just cover the ty and details.
Thu, Mar 16
Tue, Mar 14
We have the State# token yes, which enforces ordering of operations with respect to each other. So a read following a write will always occur in that order, as enforced by the state token passing.
We should probably have the test case from Trac #3207 in the test suite (I'm not sure why I didn't add it before)
Ugh. No, there's no centralized place that describes these things as far as I know.
Mon, Mar 13
Currently, there's a mismatch between the note on has_side_effects, which
says it should be False for read-only primops, and primops.txt.pp, which
makes it True for these.
What's the rationale here? The commit log is a bit brief :)
I don't think I wrote this code, but my guess is that it has to do with proper handling of Ctrl-C. Can we still correctly interrupt compilation during the gcc phase without this?
Thu, Mar 9
If I understand correctly this is saying that loading the .a is faster than loading the .so?
Wed, Mar 8
It seems to be 80MB on disk, which comparing to an unpacked binary dist I have lying around (8.0.1) looks to be about 7%.
- Simplify; the way I was doing this was wrong
- Don't build a GHCi lib for the GHC package
Good point about the GHC package. The logic is here: https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/ghc.mk;8e053700f9357c1b9030c406130062795ae5015c$603-611
Mon, Mar 6
Ok, thanks for taking the time to explain the rationale for the design. I understand that things are evolving, my main concern is that we should be careful to capture the rationale in such a way that someone reading the code in the future can understand the constraints on the design - so preferably include Notes that explain why things are the way they are (in particular why we need to parse messages in the proxy), or use wiki pages with links from the code.
I don't think I ever use #if defined X, and I prefer #if defined(X) over #ifdef. But if we're moving towards having configuration symbols be always defined, it doesn't really matter. I agree with @erikd that whatever style is agreed on should be automatically linted.
Thu, Mar 2
What effect did this have on nofib?
Wed, Mar 1
Harbourmaster failed, bad base revision for some reason?
Suggested fixes for OS X
Tue, Feb 28
Why does the proxy need to understand the content of messages, rather than just forwarding data in both directions whenever it arrives? In fact, it makes me wonder whether the proxy can't be a script wrapping netcat or something like that. Perhaps the answer to this is the extra SlaveMessage protocol for sending files - but I wouldn't object to making this part of the main protocol, unused in the case of a local server. It's quite confusing that we have these extra messages exchanged between the slave and proxy in certain circumstances.
Yes, that looks better.
Feb 25 2017
Feb 23 2017
A magical type class is a neat idea.
Looks like the test is failing on OS X:
Feb 22 2017
Feb 21 2017
necessary, but not sufficient perhaps. I look forward to seeing what else you find!
- Add a test
- Suggest -rdynamic in the docs
@bgamari I'd be happy to change the flag name if you can think of anything better. -flink-whole-static-hs-libs maybe?
Is this a bunch of patches squashed together? Could they be put into separate diffs? It would be nicer to keep the changes separate in the history, and it's not really possible to review this.
Well ok. I did leave it there deliberately, but I agree it's weak.
Feb 20 2017
Feb 15 2017
Feb 14 2017
Feb 13 2017
Feb 11 2017
Yeah, this code is probably over 20 years old and hasn't had much love since then. Thanks for cleaning it up!
In general I support having this, however as it stands there are too many problems.
- It needs to work for all configurations (TABLES_NEXT_TO_CODE, profiling)
- There's a great deal of overlap with existing code in other places (the GHCi debugger, GHCi itself, and probably bits of the code generator). If this is being brought into the GHC tree we should at least make some effort to de-dup so that we don't have yet more dependencies on representations.
Feb 10 2017
Yep, LGTM, as long as the IO tests all pass.
Feb 9 2017
Fine modulo one wibble below.
Feb 2 2017
Only had time to take a brief look I'm afraid, but my thought was why can't we pass the State# token that we already have to noDuplicate#, rather than grabbing a new one with runRW#?
It looks like this was committed despite the performance regressions in perf/compiler/all.T. What's the plan here?
Feb 1 2017
I'll run make test with the GHCi way both with and without computed gotos and see which takes longer.
Jan 27 2017
These two changes would have been better separated, I think.
I don't have strong opinions on this, but I do remember libstdc++ being a problem in the past. What does this do to the ghcilink003 test?
Jan 26 2017
While you're noodling with lazy ST, maybe I could draw your attention to Trac #11760, just in case you feel like fixing it?
I'd still really like to see some measurements, since there's a complexity cost to doing this.
Jan 25 2017
First pass, I didn't read everything but I have a bunch of questions that should help me understand it. It actually doesn't seem that complicated, it's just plumbing things around, so the main thing for me is being able to understand the data types and the transformations, I think that could be clearer in the comments.
set the flag too
Jan 23 2017
It replaces a single dispatch point with multiple ones. This improves CPU branch prediction.
Have you measured the difference? Did you look at the generated asm to check that it's doing the right thing?
This will need significant reworking, it needs to be rebuilt on top of the support for NUMA in the block allocator. I'd be happy to advise if anyone is excited about reviving it.
Jan 19 2017
Jan 18 2017
I wouldn't want to speculate about how to fix the graph-colouring allocator before we have some concrete evidence about what the problem is.
Jan 16 2017
We should fix the .gitignore too, I have no idea why it has foo*
Jan 13 2017
Looks like that +20% size increase deserves investigating too.
one more :ghc-flag:
Thanks for the review @dfeur!
Jan 12 2017
Jan 11 2017
Just a couple of wibbles below
The compiler performance regressions are a bit worrying. We should understand those before committing. Perhaps removing the LNE analysis from CoreToStg will help?
Yes, I took a look at this yesterday, I think it's ok. After a bit of thought I realised that plusForeignPtr :: ForeignPtr a -> Int -> ForeignPtr b can't do anything to the finalizer, because it's pure. In the same way that castForeignPtr can't have any effect on the finalizer. But you're probably right that we ought to document it.