[GHC] #8326: Place heap checks common in case alternatives before the case

[GHC]

#8326: Place heap checks common in case alternatives before the case
-------------------------------------+-------------------------------------
              Reporter:  jstolarek   |            Owner:  jstolarek
                  Type:  task        |           Status:  new
              Priority:  normal      |        Milestone:
             Component:  Compiler    |          Version:  7.7
            Resolution:              |         Keywords:
      Operating System:              |     Architecture:  Unknown/Multiple
  Unknown/Multiple                   |       Difficulty:  Unknown
       Type of failure:              |       Blocked By:
  None/Unknown                       |  Related Tickets:  #1498
             Test Case:              |
              Blocking:  8317        |
Differential Revisions:  Phab:D343   |
-------------------------------------+-------------------------------------

Comment (by jstolarek):

 Thanks for detailed explanation. I was a bit concerned about all that
 extra stuff like saving cost centres in the general case. Don't we need to
 worry that any of these will impact performance of the compiled code?

 > The difficulty here is that it's hard to find out whether the branches
 allocate without running the code generator on them

 Yes, I believe this was our conclusion when we discussed that during my
 internship. I don't see how to use `StgCmmMonad.getHeapUsage` to implement
 the solution. We compile all the alternatives in one go by calling `cgAlts
 (gc_plan,ret_kind) (NonVoid bndr) alt_type alts`, whereas to apply any of
 the criteria that you proposed we would need to compile the alternatives
 one by one and analyse their heap usage. My understanding is that if we
 simply call `cgAlts` in a lambda passed to `getHeapUsage` we will only
 know how much heap total is used by the compiled alternatives but we won't
 have any detailed knowledge about each of the alternatives. Is that
 correct?

 > But before doing that, the first thing is to decide what the criteria
 should be.

 It's a bit hard to tell without doing the actual implementation and
 measuring the results. I guess there will be some programs that work
 better with the first criterion and some that work better with the second
 criterion. That being said, I'd go with the first one. Slightly larger
 binaries are a small price to pay for possibility of having better
 performance.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8326#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler