#7596: Opportunity to improve CSE -------------------------------------+------------------------------------ Reporter: simonpj | 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: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Hmm, tricky. The Increase in allocation happens in `check_perim` (which produces quite ugly code; if this were real code I’d suggest the author to put in some strictness annotation on the floats...). There are multiple calls to `point_color`, which call `np` resp. `nq` on the coordinates of its arguments. These calculations are shared. How does that increase allocations? Hard to tell, even with ticky-ticky-profiling. But it seems that there is still stuff floating past multi-way cases, and it is hard to avoid. If there is a nested expression `(C1 (C2 x))`, and `(C1 (C2 x))` is worth floating on its own, it is floated past multi-way- cases, preserving existing behavior. But if `C2 x` is also optimistically floated out, it is now outside the multi-way case and might be CSEd there with values from other branches, even if `C1 lvl` itself gets floated back in. But then, I’m not entirely sure that this is main reason for allocation increase. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7596#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler