- User Since
- Jun 6 2014, 12:32 PM (151 w, 2 d)
Oh, I really liked this change :(
Fri, Apr 21
I don't understand why this would be faster, could you explain?
Tue, Apr 11
I would be inclined to go with HscAsm. Is bytecode that much faster?
Looks like this was unused since b49f7dceb6c2d12c89c947fa0f7f7cb935912de3. Guess there's no point keeping it around.
Mon, Apr 10
By the way, you could also just put the cmm file in the base package, and not have to touch the rts at all.
Sun, Apr 9
I'd be happier if we had some more decent tests, that would be less likely to pass under a completely broken implementation.
Is this still pertinent?
Good point. I have not tested that, as I didn't need ghci for what I was doing.
Hi @trofi, I've only been half-following this series of commits, but I'm wondering whether there is any documentation on the intended meaning of make install in various configurations, since make install working when crosscompiling is essentially a new feature? Maybe the wiki page for crosscompiling would be a good place?
Sat, Apr 8
Fri, Apr 7
My understanding is that
mk/test.mk:TEST_HC_OPTS = -dcore-lint -dcmm-lint -no-user-$(GhcPackageDbFlag) -rtsopts $(EXTRA_HC_OPTS)
should mean that all tests run with -dcmm-lint by default. Does it not work for cmm_src tests?
Otherwise this breaks if the used compiler fails to understand this directive. (looking at you clang!)
Thu, Apr 6
Wed, Apr 5
- Add some more seqType calls, and an explanatory Note
Tue, Apr 4
- simplifier: Don't force sc_hole_ty
I confirmed this patch still dramatically reduces DynFlags space usage locally (3694 MB total memory in use -> 1033 MB total memory in use).
Mar 30 2017
Nope, but feel free. I wasn't looking to get involved with major structural changes to these complicated modules (Demand and DmdAnal). If all the *Dmd types can be made fully strict without causing a significant increase in work then that would be an improvement.
Mar 28 2017
Update T10858 numbers
Mar 27 2017
Mar 23 2017
Mar 19 2017
Also, the stack check code I wrote is definitely wrong, and needs to be fixed in a different way for each argument type (Word# or Float# or Double#). I'm not sure exactly what the right form is, and it would be rather difficult to test; indeed I'm not completely sure whether it is even necessary.
This seems to have turned into a mess...
If Cmm is not a convenient option, it seems to me like even an FFI call to C would be more efficient (no allocation or branches, just a call/ret).
Mar 18 2017
Yeah, in practice it seems to not be as easy as I hoped :(
Mar 17 2017
I was imagining doing something like
It almost seems like it would be easier to implement these in cmm; and more efficient too as you could transfer via the stack rather than allocating a ByteArray.
This seems fine to me aside from the confusing comment. Did you mean that the case on HostPlatform gives the wrong result when cross-compiling (which you fixed), or that the AC_RUN_IFELSE gives the wrong result when cross-compiling? AC_RUN_IFELSE doesn't actually run anything when cross-compiling, so either way the new comment is wrong. (See https://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Runtime.html).
Mar 13 2017
What about Trac #3207? The issue there also applies to most of these, but maybe not the thaw/freeze ones.
Mar 11 2017
This is wrong, see https://www.schoolofhaskell.com/user/snoyberg/general-haskell/advanced/evaluation-order-and-state-tokens. Could you add a note that explains this?
Mar 8 2017
This is the first commit with the error on Windows about unix64.S--a file from libffi which, from its name, I would guess we should not be attempting to compile on Windows.
I don't know what these tests were supposed to test, but I'm fairly sure that whatever it was is not reflected by the current test behavior.
If I understand correctly this would also increase the size of the unpacked binary distribution by a significant amount (maybe 20% by my estimates). Have you measured that yet?
You don't need .alt_entry any more if you are putting .no_dead_strip on the info tables (it could only be harmful, by causing even more things to stay live).
Mar 7 2017
Mar 6 2017
We can't use an unboxed tuple because it would require strict evaluation of the updater function (the reason atomicModifyMutVar# can be atomic is that it just builds a thunk).
Mar 5 2017
Mar 4 2017
Mar 3 2017
Abandoning in favor of D3270.
Hi @ruperthorlick, thanks for your work on these two tickets!
Mar 2 2017
Also it's quite unclear from the perf.haskell.org graph what happened here, maybe the Early inline patch number is from a non-rebased version of the patch?
But the actual number (line 982) was not changed.
You say "While we do not yet enable mmap for ios builds. If we later do, we must not try to mmap r+w+x, on iOS as that clearly fails." Does "not yet" mean even after this entire set of MachO linker-related patches, so this will still be effectively dead code?
- Make CompleteMatch field names more descriptive, and add comments
Mar 1 2017
Edsko suggests (and I agree) that we ought to describe orphan COMPLETE pragmas as "not supported" rather than "not allowed" (since there's no reason why we couldn't support them, in principle).
Feb 28 2017
Nofib results for D3217 here: https://perf.haskell.org/ghc/#revision/d0508ef001e9c93920f6eb066cab5e79041cb886
I think this should actually be squashed into whatever (upcoming?) diff uses the new fields, as it's not really reviewable without, nor does it make much sense to land separately.
If this is experimental, then what experiment do you plan to do?
Currently this won't build on non-MachO platforms, so I didn't look much past that.
Adding a flag is what D3177 does.
Agree with adding a comment here, though this seems a bit verbose to me.