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

#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
participants (1)
-
GHC