#9434: GHC.List.reverse does not fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.9 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:4 simonpj]:
That looks helpful. But allocation probably should never go up. Do you know why it does so in constraints?
I use `-ticky` a lot to track down these kind of things.
Simon
I don't know how to use `-ticky` yet. How would I get nofib compiled with that? My best guess about constraints is that it's all about the evil spirit in the machine, by which I mean the inliner. One phenomenon I saw in some of my little tests was that inlining thresholds make things rather less compositional than one might like. That is, if `f x = ... g ...` and `g y = ... h ...`, then inlining `h` can make `g` "too big", so then `g` won't be inlined in `f` unless someone leans on the compiler to do so. My bet is that something that calls reverse is not being inlined as a result, and therefore some other optimization opportunity is missed. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9434#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler