David
Thanks for moving my early-inline patch series to HEAD.
You'll remember that I pushed this patch (below) to spj-early-inline2
Can you be sure to cherry-pick this one too? It's important and I don't see it
in HEAD yet. I'm surprised that there isn't a validate failure (T9505 if
memory serves - see attached).
Simon
commit 002192aa8df463ae945e8a94147cfc1d848f43a5
Author: Simon Peyton Jones <[email protected]>
Date: Fri Feb 24 16:55:36 2017 +0000
Fix a nasty bug in CoreSubst.collectBindersPushingCo
The bug wsa in the use of (mkNthCo 0) to get the argument
part of a function coercion. Not so! Now (->) takes four
arguments so that 0 should have been 2.
Enough with magic numbers. I defined decomposeFunCo, and used
it throughout. Much nicer now; and correct.
The nete effect, incidentally, was that T9509 was failing to
specialise. (And that was the initial reason for introducing
collectBindersPushingCo in the first place.)
--- Begin Message ---
Too late. I fixed the bug in T9509 and pushed to spj-early-inline2.
There’s a series of three patches. Should be easy for you to transfer to
wherever you are now working.
Simon
From: David Feuer [mailto:[email protected]]
Sent: 24 February 2017 14:54
To: Simon Peyton Jones <[email protected]>
Subject: RE: Progress on early inline
No, please don't. I've fixed up various things since. I'll push a better
version somewhere shortly.
David Feuer
Well-Typed, LLP
-------- Original message --------
From: Simon Peyton Jones <[email protected]<mailto:[email protected]>>
Date: 2/24/17 4:11 AM (GMT-05:00)
To: David Feuer <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>, Ben Gamari
<[email protected]<mailto:[email protected]>>
Subject: RE: Progress on early inline
Thanks for your work on this.
Ah 9509. That makes more sense.
I'll try to build spj-early-inline2. How does it differ from spj-early-inline?
Incidentally the top patch in spj-early-inline2 has a long commit message that
looks like a squash of all the earlier commits. But it isn't... it's just a
few wibbles. Mildly misleading commit message.
On this diff:
diff --git a/testsuite/tests/th/TH_Roles2.stderr
b/testsuite/tests/th/TH_Roles2.stderr
index 3027911..d2c6316 100644
--- a/testsuite/tests/th/TH_Roles2.stderr
+++ b/testsuite/tests/th/TH_Roles2.stderr
@@ -16,8 +16,8 @@ TH_Roles2.$tcT
TH_Roles2.$trModule
(GHC.Types.TrNameS "T"#)
1
- krep_a4im
-krep_a4im [InlPrag=[~]]
+ krep_a40L
+krep_a40L [InlPrag=[~]]
= GHC.Types.KindRepFun
(GHC.Types.KindRepVar 0)
(GHC.Types.KindRepTYPE GHC.Types.LiftedRep)
It looks as if this test should have -dsuppress-uniques, or it'll keep failing.
Simon
| -----Original Message-----
| From: David Feuer [mailto:[email protected]]
| Sent: 24 February 2017 04:26
| To: Simon Peyton Jones <[email protected]<mailto:[email protected]>>
| Cc: [email protected]<mailto:[email protected]>; Ben Gamari
<[email protected]<mailto:[email protected]>>
| Subject: Re: Progress on early inline
|
| An update to the update: Ben says the new debug output is more correct than
| the old one, and Reid concludes from this that we should try to find out why
| so we can make that happen on purpose. The remaining problem is T9509, which
| I mistakenly called by the wrong name in my last message.
|
| David
|
| On Thursday, February 23, 2017 10:08:41 PM EST David Feuer wrote:
| > I've started putting up separate differentials for your various
| > commits on Phabricator. I'll let you know when that's done. We've made
| > some headway on the test failures:
| >
| > The problem with T4030 turns out to be quite unrelated to your
| > changes--the use of catchException rather than catch in the definition
| > of forkIO is to blame. Apparently, your patch just made the problem
| > show up in that particular test case. I'll open a ticket and put up a
| > differential to fix it.
| >
| > The debug test failure is somewhat mysterious to Reid and me; we can't
| > even tell if it's actually a problem. Reid is going to check with a
| > couple other people to find out for sure.
| >
| > [T9509] *does* seem to be related. The foo unfolding is getting eta
| > expanded again. I imagine this has something to do with the early
| > inlining of the IO operations, but I don't know. We end up with
| >
| > Rec {
| >
| >
| > We previously got
| >
| > Rec {
| > Arity=3,
| >
| >
| > David Feuer
| > Well-Typed LLP
|
--- End Message ---
_______________________________________________
ghc-devs mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
