[GHC] #10613: Mechanism for checking that we only enter single-entry thunks once

[GHC]

#10613: Mechanism for checking that we only enter single-entry thunks once
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.10.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Other             |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by nomeata):

 Nooo, where is the longish text I wrote here yesterday? :-( I hate it when
 that happens. Darn, let’s see what I can remember. grnrl.

 > I thought I only enabled it for thunks, but it also seems to be present
 for two functions, and only there count multiple entries... Weird.

 Still weird. If I add my counting indirection to everything, I get
 segfaults. So I guard it with `idRepArity id == 0` for now, thinking I
 would only add it to thunks. But the above report shows some that have
 “Non-void arguments”, but still `idRepArity id == 0`; this is one example:

 {{{
 let {
   sat_s7uy [Occ=Once] :: GHC.Types.Double -> GHC.Types.Double
   [LclId, Str=DmdType] =
       \r srt:SRT:[] [x_s7ux] GHC.Float.timesDouble x_s7ux y_s7uu;
 } in
   case Main.$wintegrate1D 0.0## ww3_s7uw sat_s7uy of ww4_s7uz {
     __DEFAULT -> GHC.Types.D# [ww4_s7uz];
   };
 }}}

 Why does this have a zero `idRepArity`?  Why does it not crash? Is it
 because it is used as an argument to a function, and hence no fast calls
 occur?

 > Also, these 500000-times allocated thunks are not really unused, are
 they?.

 No, they are not. These are constructors, where entries are not counted. I
 extended the ticky report to be a bit more explicit about the kind of
 things these names are, i.e. distinguish cons from thunks, and for thunks,
 indicate which are one-shot and which are static.

 > Two total entries for a thunk (sat_s7vH) that has been allocated once
 and called once? Maybe there was a heap check inbetween?

 No, this is simply a bug in the ticky code, where there are two calls to
 `tickyEnterThunk`
 (likely introduced by 99d4e5b4a0bd32813ff8c74e91d2dcf6b3555176, possibly
 due to a merge mistake).

 The latter two improvements are at Phab:D2014, mostly to get phab to test
 the commit (which does not seem to happen... why?).

 I now need to wrap my head around how to do the counting for functions. My
 counting indirection does not work as it is, because functions are entered
 differently. So I either have to create a counting indirection that works
 for functions (but I don’t know yet if a single one would work for all
 types of functions), or add the counting code to the function itself. In
 this case, the function closure needs an additional field for the counter.

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