[GHC] #7596: Opportunity to improve CSE

[GHC]

#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