[GHC] #5889: -fno-prof-count-entries leads to linking errors

[GHC]

#5889: -fno-prof-count-entries leads to linking errors
-------------------------------------+-------------------------------------
        Reporter:  akio              |                Owner:  bgamari
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  8.3
      Resolution:                    |             Keywords:
Operating System:  Linux             |         Architecture:  x86_64
                                     |  (amd64)
 Type of failure:  GHC rejects       |            Test Case:
  valid program                      |  profiling/should_compile/T5889
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by duog):

 I found your analysis instructive osa1, thank you.

 My current understanding is now that the cost-centres are, modulo bugs,
 removed when they aren't wrapping any work. I don't think we have any
 examples here of erroneous cost-centre removal, do you agree?

 As for how to implement alternative (2) in comment:10, Note [inline scc]
 summarises the difficulty:
 {{{
 -- Note [inline sccs]
 --
 -- It should be reasonable to add ticks to INLINE functions; however
 -- currently this tickles a bug later on because the SCCfinal pass
 -- does not look inside unfoldings to find CostCentres.  It would be
 -- difficult to fix that, because SCCfinal currently works on STG and
 -- not Core (and since it also generates CostCentres for CAFs,
 -- changing this would be difficult too).
 }}}

 Could we collect SCCs from all unfoldings in `corePrepPgm`, and union them
 with the result of `myCoreToStg`? What could go wrong? Are there any
 pathological scenarios where large numbers of SCCs would be created?

 That would fix the bug alluded to in the note, so if we go forward with
 that idea let's not forget to update the note and create a ticket for the
 task of reevaluating the sites referencing said note.

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