#3697: Method selectors aren't floated out of loops
--------------------------------------------+------------------------------
Reporter: rl | Owner:
Type: bug | Status: closed
Priority: low | Milestone: 7.6.2
Component: Compiler | Version: 6.13
Resolution: fixed | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Runtime performance bug | Unknown/Multiple
Test Case: | Difficulty: Unknown
Blocking: | Blocked By:
| Related Tickets:
--------------------------------------------+------------------------------
Changes (by nomeata):
* status: new => closed
* difficulty: => Unknown
* resolution: => fixed
Comment:
With todays HEAD, I get good code:
{{{
T3697.foo =
\ (@ a)
($dEq :: GHC.Classes.Eq a)
($dNum :: GHC.Num.Num a)
(as :: [a]) ->
let {
ds :: a
[LclId, Str=DmdType]
ds = GHC.Num.fromInteger @ a $dNum T3697.foo1 } in
let {
lvl :: a -> a -> GHC.Types.Bool
[LclId, Str=DmdType]
lvl = GHC.Classes./= @ a $dEq } in
let {
lvl1 :: a -> a -> a
[LclId, Str=DmdType]
lvl1 = GHC.Num.- @ a $dNum } in
letrec {
go [Occ=LoopBreaker] :: [a] -> [a]
[LclId, Arity=1, Str=DmdType <S,1*U>]
go =
\ (ds1 :: [a]) ->
case ds1 of _ [Occ=Dead] {
[] -> GHC.Types.[] @ a;
: y ys ->
let {
x :: a
[LclId, Str=DmdType]
x = lvl1 y y } in
case lvl x ds of _ [Occ=Dead] {
GHC.Types.False -> go ys;
GHC.Types.True -> GHC.Types.: @ a x (go ys)
}
}; } in
go as
}}}
Given the age of the bug, I don’t dare to guess what has fixed this. Also,
hard to make a useful testcase here.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3697#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#3698: Bad code generated for zip/filter/filter loop
--------------------------------------------+------------------------------
Reporter: rl | Owner:
Type: bug | Status: closed
Priority: low | Milestone: 7.6.2
Component: Compiler | Version: 6.13
Resolution: fixed | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Runtime performance bug | Unknown/Multiple
Test Case: | Difficulty: Unknown
Blocking: | Blocked By:
| Related Tickets:
--------------------------------------------+------------------------------
Changes (by nomeata):
* status: new => closed
* difficulty: => Unknown
* resolution: => fixed
Comment:
The new callarity analysis successfully eta-expands the monomorphic code.
For the polymorphic code, there is nothing we can do, as guest mentions in
comment:1. So I guess this can be closed.
(I did not create a test case for this because these things are hard to
test, and it is a standard application fo the callarity analysis, nothing
tricky going on here.)
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3698#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#3924: Strictness analyser missing useful strictness
-------------------------------------+------------------------------------
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: low | Milestone: 7.6.2
Component: Compiler | Version: 6.12.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture: Unknown/Multiple
Type of failure: None/Unknown | Difficulty: Unknown
Test Case: | Blocked By:
Blocking: | Related Tickets:
-------------------------------------+------------------------------------
Changes (by nomeata):
* difficulty: => Unknown
Comment:
This looks like it could be solved by the new callartiy analysis. It does
not, though, because
* all the functions are top-level functions, and callartiy analysis only
looks at local functions, and
* they are mutually recursive, which the callarity analysis does not
handle yet.
Both could possibly be fixed, but both carry an implementation and
maintenance cost, I’d like to do that lazily, i.e. depending on real-world
use cases.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3924#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#5809: Arity analysis could be better
--------------------------------------------+------------------------------
Reporter: simonmar | Owner: simonpj
Type: bug | Status: closed
Priority: normal | Milestone: 7.6.2
Component: Compiler | Version: 7.5
Resolution: fixed | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Runtime performance bug | Unknown/Multiple
Test Case: | Difficulty: Unknown
Blocking: | Blocked By:
| Related Tickets:
--------------------------------------------+------------------------------
Changes (by nomeata):
* status: new => closed
* resolution: => fixed
Comment:
Judging from the code, the new callartiy analysis should do exactly that
(see that `block` is called with two arguments). Unfortunately, there is
no small example here to verify this; but I’m optimistic. If you find that
it does not work with today’s HEAD, I’d like to hear about it.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5809#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7542: GHC doesn't optimize (strict) composition with id
--------------------------------------------+------------------------------
Reporter: shachaf | Owner: simonpj
Type: bug | Status: new
Priority: normal | Milestone: 7.8.1
Component: Compiler | Version: 7.6.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Runtime performance bug | Unknown/Multiple
Test Case: | Difficulty: Unknown
Blocking: | Blocked By:
| Related Tickets:
--------------------------------------------+------------------------------
Comment (by nomeata):
The simple example from the ticket:
{{{
(#) :: (b -> c) -> (a -> b) -> a -> c
(#) f g = f `seq` g `seq` \x -> f (g x)
foo :: (a -> b) -> [a] -> [b]
foo f = map (id # f)
}}}
produces
{{{
T7542.foo =
\ (@ a) (@ b) (f :: a -> b) (eta :: [a]) ->
GHC.Base.map @ a @ b (\ (eta1 :: a) -> f eta1) eta
}}}
without `-fpedantic-bottoms` and
{{{
T7542.foo = GHC.Base.map
}}}
with, which looks fine. The same happens to the more elaborate example in
comment:2 (middle section), `-fpedantic-bottoms` preserves the semantics
and with that we get `map2 = map`.
So it seems that situation has improved and we can close the ticket (which
should not discourage anyone who finds a situation that needs fixing to
open it again).
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7542#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7994: Make foldl into a good consumer
-------------------------------------+------------------------------------
Reporter: simonpj | Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component: Compiler | Version: 7.6.3
Resolution: fixed | Keywords:
Operating System: Unknown/Multiple | Architecture: Unknown/Multiple
Type of failure: None/Unknown | Difficulty: Unknown
Test Case: | Blocked By:
Blocking: | Related Tickets:
-------------------------------------+------------------------------------
Changes (by nomeata):
* status: new => closed
* resolution: => fixed
Comment:
Heh, forgot to reference the ticket in the push. This has now been
implemented in b63facef165b957183b65604ef99b2b8574747a5/base and requires
the calla arity analysis (cdceadf365335fdee5ffa8e6364f7fb00bc4b0f7/ghc).
This should not stop us from using superior approaches like Takano’s when
they are ready.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7994#comment:19>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#149: missed CSE opportunity
-------------------------------------+-------------------------------------
Reporter: nobody | Owner:
Type: bug | Status: new
Priority: normal | Milestone: ⊥
Component: Compiler | Version: 5.04.2
Resolution: None | Keywords: optimisations
Operating System: Unknown/Multiple | Architecture: Unknown/Multiple
Type of failure: Runtime | Difficulty: Moderate (less
performance bug | than a day)
Test Case: T149 | Blocked By:
Blocking: | Related Tickets:
-------------------------------------+-------------------------------------
Comment (by Joachim Breitner <mail@…>):
In [changeset:"393ea739567206d848f53e9ca75f532a49218694/ghc"]:
{{{
#!CommitTicketReference repository="ghc"
revision="393ea739567206d848f53e9ca75f532a49218694"
Update test cases due to call arity
Some nice improvements on already succeeding test cases (#876, #7954
and #4267)
Test #149 needed a little change, lest call arity causes a allocation
change that we do not want to test here.
}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/149#comment:27>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
