[GHC] #15832: fprintCCS_stderr (+RTS -xc) should be able to recurse into stacks that evaluated a given stack even if the latter does not come from a CAF (was: returnIO/bindIO destroys runtime explicit stack information in some cases)

[GHC]

#15832: fprintCCS_stderr (+RTS -xc) should be able to recurse into stacks that
evaluated a given stack even if the latter does not come from a CAF
-------------------------------------+-------------------------------------
        Reporter:  infinity0         |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:
       Component:  Compiler          |              Version:  8.6.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by infinity0):

 <bgamari> infinity0, have you considered simply using a more aggressive
 -fprof-* flag?
 <infinity0> bgamari: i'm already using "-fprof-auto -fprof-auto-calls
 -fprof-cafs" that seems to be the most aggressive available option
 <bgamari> ahh yes, so you are
 <bgamari> well then, that is indeed tricky
 <bgamari> can you describe where ideally you would like CCs to be
 inserted?
 <infinity0> i tried manually inserting CCs in the bad cases and couldn't
 get them working, so i don't really know
 <infinity0> but it seems to me that the logic that traverses different
 stacks to find subsequent "evaluated by" stacks, maybe can be expanded
 <infinity0> because it apparently only works when each stack except the
 last starts from a CAF
 <infinity0> i previously thought perhaps everything is supposed to start
 from a CAF but from what you're saying now it seems maybe not
 <infinity0> in which case, the "evaluated by" traversal logic ofc can't
 work for these latter cases
  * bgamari tries to work out what the stack looks like in the bad case
 <bgamari> infinity0, for what it's worth, I'm not sure this will just be a
 matter of expanding the existing stack printing logic
 <bgamari> infinity0, I suspect the information you need is actually not
 present at runtime
 <infinity0> oh :(
 <bgamari> afterall, in both cases we have tail-called
 <bgamari> so there is no stack frame to reconstruct execution from
 <bgamari> it just happens that in the good case we tail called into a CAF,
 which had a cost center
 <bgamari> I agree that this is an unfortunate behavior though
 <bgamari> I may be missing something but I think the right way to think
 about this may be from the perspective of finding a heuristic to use to
 insert the necessary CCs
 <bgamari> admittedly it's not immediately clear what that should look
 like, however
 <infinity0> yeah, going back to the original bad example, I tried changing
 it to {-# SCC test0 #-} ( {-# SCC test1 #-} \_ -> {-# SCC test2 #-} (print
 ...
 <infinity0> and this didn't fix the stack either
 <bgamari> I'll admit, that's a bit surprising
 <bgamari> oh, perhaps because it's non-updateable
 <bgamari> so you don't get an update frame

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