[GHC] #10007: Fix misattribution of Cost Centre profiles to lintAnnots

[GHC]

#10007: Fix misattribution of Cost Centre profiles to lintAnnots
-------------------------------------+-------------------------------------
        Reporter:  thoughtpolice     |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  high              |               Milestone:  7.10.1
       Component:  Profiling         |                 Version:  7.10.1-rc1
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  Incorrect result  |  Unknown/Multiple
  at runtime                         |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:  #9961             |  Differential Revisions:  Phab:D616
                                     |  Phab:D636
-------------------------------------+-------------------------------------

Comment (by scpmw):

 Yes - I investigated this again a month ago, and found that SM's fix
 didn't correct the whole problem. In fact, if I remember correctly what we
 end up with is something like

 {{{
 case scctick<SpecConstr> specConstrProgram of ...
 }}}

 In this situation the tick will fail to actually capture any cost in
 `specConstrProgram`, which will instead end up in the cost-centre next in
 the hierarchy, which happens to be `lintAnnots` (`Core2Core` before).

 As explained in D616 and #5654, this is a fairly fundamental problem: GHC
 simply doesn't implement the cost-centre semantics for function values
 correctly. Correcting this isn't exactly easy - I have been experimenting
 in the past weeks, and the best solution I can come up with (still?)
 involves a new closure type that wraps function values when they escape
 cost-centre scopes.

 Two possible solutions here: We could attempt another stopgap measure. For
 example, the above code should probably in-line as it is only used once.
 Building the full solution will still need a bit more tinkering, but I
 might be able to make a proposal soon-ish (... just need to get it to stop
 crashing. Seems getting register saving right can be surprisingly tricky).

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