Re: [GHC] #4945: Another SpecConstr infelicity
#4945: Another SpecConstr infelicity -+-- Reporter: batterseapower | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.0.2 Component: Compiler|Version: 7.0.1 Resolution: fixed | Keywords: Testcase: simplCore/should_compile/T4945 | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: Runtime performance bug | -+-- Changes (by igloo): * status: merge = closed * resolution: = fixed Comment: Only performance, and not a regression since 7.0.1 at least, so not merging at this stage of the release cycle. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4945#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4945: Another SpecConstr infelicity
#4945: Another SpecConstr infelicity -+-- Reporter: batterseapower|Owner: Type: bug | Status: merge Priority: normal|Milestone: 7.0.2 Component: Compiler | Version: 7.0.1 Keywords:| Testcase: simplCore/should_compile/T4935 Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Changes (by igloo): * milestone: = 7.0.2 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4945#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4945: Another SpecConstr infelicity
#4945: Another SpecConstr infelicity
-+--
Reporter: batterseapower|Owner:
Type: bug | Status: merge
Priority: normal|Milestone:
Component: Compiler | Version: 7.0.1
Keywords:| Testcase: simplCore/should_compile/T4935
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: Runtime performance bug
-+--
Changes (by simonpj):
* status: new = merge
* testcase: = simplCore/should_compile/T4935
Comment:
Right. I came to the same conclusion.
{{{
Mon Feb 7 10:25:37 GMT 2011 simo...@microsoft.com
* Fix Trac #4945: another SpecConstr infelicity
Well, more a plain bug really, which led to SpecConstr
missing some obvious opportunities for specialisation.
Thanks to Max Bolingbroke for spotting this.
M ./compiler/specialise/SpecConstr.lhs -21 +35
}}}
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4945#comment:4
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4945: Another SpecConstr infelicity
#4945: Another SpecConstr infelicity
-+--
Reporter: batterseapower| Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.0.1 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: Runtime performance bug
-+--
Comment(by batterseapower):
OK, I got it. All you need to do is replace varUsage with:
{{{
varUsage :: ScEnv - OutVar - ArgOcc - ScUsage
varUsage env v use = case lookupHowBound env v of
Just RecArg - SCU { scu_calls = emptyVarEnv
, scu_occs = unitVarEnv v use }
Just RecFun - SCU { scu_calls = unitVarEnv v [(emptyVarEnv, [])] --
Added so we get specialisations even if function used in trivial way (i.e.
as a variable)
, scu_occs = emptyVarEnv }
Nothing - nullUsage
}}}
Otherwise the pattern guard on (lookupVarEnv bind_calls fn) in specialise
fails, so we don't even get to call callsToPats.
I think this is the right change, because it should also mean that we get
call pattern specialisations for locally-bound functions that are e.g.
stored inside a data structure.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4945#comment:3
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #4945: Another SpecConstr infelicity
#4945: Another SpecConstr infelicity
-+--
Reporter: batterseapower| Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.0.1 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: Runtime performance bug
-+--
I'm beginning to sound like a broken record, but SpecConstr still doesn't
seem to be right! The last problem has been fixed, but I've found a new
one.
Please observe the output of compiling the attached code with:
{{{
./ghc -fforce-recomp -c -dverbose-core2core -O2 -fno-liberate-case
STUArray-Rewrite2.hs
}}}
In the output of SpecConstr we have a local letrec:
{{{
(letrec {
$wa_s1G7 [Occ=LoopBreaker]
:: forall s_aJm.
Data.Array.Base.STUArray
s_aJm GHC.Types.Int GHC.Types.Int
- GHC.Prim.Int#
- GHC.Prim.State# s_aJm
- (# GHC.Prim.State# s_aJm, () #)
[LclId, Arity=3, Str=DmdType LLL]
$wa_s1G7 =
\ (@ s_aJm)
(w_s1FS
:: Data.Array.Base.STUArray
s_aJm GHC.Types.Int GHC.Types.Int)
(ww_s1FV :: GHC.Prim.Int#)
(w_s1FX :: GHC.Prim.State# s_aJm) -
case GHC.Prim.# ww_s1FV ww_s1FN
of wild_Xj [Dmd=Just A] {
GHC.Types.False -
case w_s1FS
of wild_aTj [Dmd=Just L]
{ Data.Array.Base.STUArray ds1_aTl [Dmd=Just U]
ds2_aTm [Dmd=Just U]
n_aTn [Dmd=Just U(L)]
ds3_aTo [Dmd=Just A] -
case n_aTn
of wild_aTs [Dmd=Just A]
{ GHC.Types.I# x_aTu [Dmd=Just L] -
case $wa_s1G0
@ s_aJm
w_s1FS
(GHC.Types.I# ww_s1FV)
0
(GHC.Prim.-# x_aTu 1)
w_s1FX
of wild_XUw [Dmd=Just A]
{ (# new_s_XUB [Dmd=Just L], r_XUD [Dmd=Just A] #) -
$wa_s1G7
@ s_aJm w_s1FS (GHC.Prim.+# ww_s1FV 1) new_s_XUB
}
}
};
GHC.Types.True - (# w_s1FX, GHC.Unit.() #)
}; } in
$wa_s1G7)
}}}
This is a local recursive loop with an invariant first argument (w_s1FS)
that is recrutinised every time! This seems deeply uncool.
This is with HEAD (7.1.20110203, incorporating the patch Fix typo in
SpecConstr that made it not work at all)
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4945
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4945: Another SpecConstr infelicity
#4945: Another SpecConstr infelicity
-+--
Reporter: batterseapower| Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.0.1 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: Runtime performance bug
-+--
Comment(by batterseapower):
I see what is going on here. Since this is a local letrec, you don't
generate any specialisations from the RHS call patterns unless at least
one call pattern is boring. However, since the body doesn't apply *any*
arguments at all to the function, SpecConstr doesn't detect any calls! How
amusing :-)
A quick and easy hack that would probably solve it would be to replace
SpecConstr:1486 with:
{{{
any isNothing mb_pats || null mb_pats
}}}
I can't test this right now.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4945#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4945: Another SpecConstr infelicity
#4945: Another SpecConstr infelicity -+-- Reporter: batterseapower| Owner: Type: bug | Status: new Priority: normal| Component: Compiler Version: 7.0.1 |Keywords: Testcase:| Blockedby: Os: Unknown/Multiple |Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Comment(by batterseapower): OK, I did actually manage to try my fix, and I'm still not getting specialisation of that function. That observation might be part of the problem, but it's not the whole story. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4945#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
