- User Since
- Jun 6 2014, 12:32 PM (159 w, 6 h)
Wed, May 31
We should not just force PIC on all LLVM users.
May 15 2017
I'm confused about whether the new flag is to be named -fPIE, -PIE or -pie.
So when libffi eventually does have a new release will we still need the new dependency libtldl-dev to build GHC?
That's helpful but wasn't what I wanted to know about. What's this stuff about libtool?
I hear something about a new dependency. What is it and why is it needed?
May 12 2017
As I just wrote on Trac #13689, I don't think that issue is really "about" rights. It strikes me as a bug that these definitions do not get unfoldings by default; and that bug could affect many similar definitions in user programs.
May 8 2017
May 3 2017
I still don't understand what's going on here but if the aim is to save allocating 2 words per unsafeInterleaveIO then let's not do it.
In any case this code is incomprehensible as written.
May 2 2017
May 1 2017
This looks like a good example of when not to use Monoid, but at least some description of what the meaning of the monoid operation is would be a good thing.
- Reduce perf numbers
See ensuing discussion at Trac #13378.
Apr 30 2017
OK, well, it's still the case that -dcmm-lint is on for all tests by default so there is no need to add it to particular tests.
I realize this is kind of inconvenient to change, but I would be happier if we just called this thing stWorld#, runST#, etc. rather than having to remember the trivia that fakeWorld# is used for ST.
This change also means that in the mean time we get to strip dead code--we just don't get to strip the info tables attached to dead code.
Isn't there a workaround in that ticket? The new behavior is sort of logical after all.
Oh, I really liked this change :(
Apr 21 2017
I don't understand why this would be faster, could you explain?
Apr 11 2017
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.
Apr 10 2017
By the way, you could also just put the cmm file in the base package, and not have to touch the rts at all.
Apr 9 2017
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?
Apr 8 2017
Apr 7 2017
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!)
Apr 6 2017
Apr 5 2017
- Add some more seqType calls, and an explanatory Note
Apr 4 2017
- 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!