Simon and I had a call about the Eq situation, and we resolved to do a bigger refactor of TrieMaps to resolve the situation :) Onwards!
Apr 25 2018
Apr 12 2018
Apr 9 2018
You should be able to use an unboxed tuple and then use a pattern synonym to make it all look nice again. The pattern synonym will get inlined, and that might reduce the allocation.
Apr 2 2018
I ran the perf tests and there seems to be a modest bump in allocations, maybe because the call sites of the unifier aren't inlining into the worker function. I suppose an easy way to fix this problem is to change DeBruijn to be an unboxed tuple. I'll give that a try.
Apr 1 2018
Mar 31 2018
Do performance tests back up these claims?
The first and foremost motivation for the patch is that I want to add a TrieMap'ified version of the unification algorithm, and it will be easier to compare the two / keep them in sync if they are both using the same deBruijn numbering mechanism. (Indeed, Simon was the one who suggested, probably years ago, that we should try this.) Benefits beyond that are icing on the cake.
Feb 4 2018
Dec 1 2017
Nov 24 2017
make this actually work
There are a lot of unknowns with this patch (e.g., whether or not it will cause some subtle bugs because a TyThing is not wired up) but Simon and I are in agreement that it's worth a try. Unfortunately harbormaster is segfaulting right now but I know this patch validate(d) on OS X without any trouble.
Nov 23 2017
This seems great to me, but then I don't understand why -O0 suppressed this originally.
Still waiting for the test :) The patch looks OK, though.
Nov 17 2017
one more validate fix
Nov 16 2017
I think this patch is a strict improvement over the current situation, but I don't think it is correct: see my comment about package database stacks.
We're going to go the route of the other revision.
OK, in this case we need to flip this patch on its head. Today, if you compile with -O0, GHC will not warn about ill-placed UNPACK pragmas. We should make this be the case. And then I need to add some more logic to have this warning be suppressed when Backpack is being used,.
Nov 5 2017
Oct 30 2017
fix validate failures
Oct 29 2017
Oct 17 2017
Don't forget to check in the expected stderr.
Oct 12 2017
I mentioned this changeset to simonpj, and his thought was 12% perf improvement was not all that much for a decent increase in code complexity (2x speed up would be much better). Mentioning it on this ticket so I don't forget.
Oct 8 2017
Oct 7 2017
don't print kinds when they are boring
Oct 4 2017
Oct 3 2017
Oct 1 2017
Sep 30 2017
Had an offline conversation with duog about this patch. There is some delicate coroutining going on between the main scheduler thread of the new parallel compilation phase, and the "yield" mechanism inside HscMain. There should be a note on this.
duog and I chatted about this offline, and we came up with a scenario where this change is unsound.
Sep 26 2017
I'm not done reviewing, but let me add some initial comments.
Sep 20 2017
I like to cite the README here: https://github.com/ndmitchell/ghc-make for demonstrating why *anything* is better than what we have in ghc --make today. It's pretty simple, really: ghc --make *always* parses the module headers of every module in your package, no ifs ands or buts. A shake based approach can do a single database load, and a quick probe of the timestamps of all files, before deciding no recompilation must be done.
Aug 29 2017
Well, this clearly fixes a bug, so I don't mind taking it. But I feel like we have similar logic for this (filter out self import) elsewhere in GHC, so I wonder if we've hit the root cause.
Aug 24 2017
It... seems like I have managed to convince Richard that this patch won't blow things up... so I guess we can merge it :)
I like the new approach!
It would be easier to give a judgment on HPT in an IORef if I knew what design forces conspired to put you into this regime. This particular change comes with the risk that some callers are hanging on to HPT because they believe it won't update, when it actually does.
Aug 13 2017
It will take me some time to review this patch, but there are two things I would think about. First, consider using threadscope or a similar tool to get traces showing how long parsing/typechecking/codegen take as "bars" (think similar to nvrtc; Google it) which will help you get a qualitative perspective on how much your patch is helping. If you need a machine with more cores to test on I can volunteer one. Second, take care on whether or not all the thunks are being forced between stages, or if you're actually foisting work into a later phase (which can defeat parallelization.)
I feel like this commit could be made more type-safe, since there seems to be some implicit invariant on how IEAvails is supposed to be inserted in IEs. I'm sympathetic to the desire to avoid API breaking changes but I think doing it properly is it worth it here.
Aug 7 2017
Oh! Rep is going to be a AlgTyCon, with an AbstractTyCon RHS.
Aug 6 2017
Can such a module be compiled?
Aug 5 2017
@duog, you are right. I have written a ticket about the issue:
Aug 1 2017
Jul 18 2017
Jul 15 2017
Jun 14 2017
I'm a grumpy curmudgeon and don't want to have to learn new locations for modules, but don't let me stop you :) One thing that would be kinder to all GHC API users (who are now going to have to rewrite all of their imports) is to create an old-ghc package which reexports all of the modules under their old names. Might be helpful.
May 16 2017
May 15 2017
May 13 2017
OK! Onwards to a brave new future :)
Apr 30 2017
I can't commit to figuring out how to deal with the regression (Trac #13604) in time for 8.2, so better to leave things the way they were previously :/
Apr 25 2017
Apr 22 2017
Apr 11 2017
So, to explain the history behind -fwrite-interface, it was added (ab105f83dcd5f9094a9edb0f0c8266fba6f3c808) because I noticed that -fno-code wasn't writing out interface files, and this meant that recompilation didn't work in "flycheck" mode because you couldn't avoid retypechecking a file that hadn't changed. I added a new flag rather than change the behavior of -fno-code because it was (a) more convenient from an implementation perspective, and (b) preserved BC (for arguably bad behavior.)
I lean towards interpreter (because I want -fno-code to run as quickly as possible), but what seems important to me is the ability to toggle between the two, similarly to how -fobject-code can be used to force GHCi to asm rather than interpret.
Apr 6 2017
It basically needs to be rewritten for the new Backpack stuff.
No, but I landed the fix that worked for me, see 5db415580e0738f934e35b7012fe35a79b7e97c7
Apr 3 2017
Apr 2 2017
Mar 31 2017
Well, that's the problem, I don't really know how to do that; all I know is that I change my environment file and ask GHC to "reload its configuration", it would be surprising if it didn't get picked up...
Mar 30 2017
I don't think the extraPkgConfs test is enough. If someone applies removeGlobalPkgConf we won't notice it if we run the function on the empty list. I guess the solution here is to get an actual data type (I never liked the function anyway.)
Mar 29 2017
Better cleaner implementation
Mar 27 2017
This got merged (but the commit message was truncated so Phabricator didn't see it.)
Mar 26 2017
fix validate error
Mar 22 2017
Mar 20 2017
Mar 19 2017
Mar 17 2017
I reverted it. I'll look more carefully why the boilerplate isn't being applied.