#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 osa1): Simon, we were wrong about CorePrep not dropping unfoldings for exported ids, it really drops all unfoldings. There's a note {{{ {- Note [Drop unfoldings and rules] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We want to drop the unfolding/rules on every Id: - We are now past interface-file generation, and in the codegen pipeline, so we really don't need full unfoldings/rules - The unfolding/rule may be keeping stuff alive that we'd like to discard. See Note [Dead code in CorePrep] - Getting rid of unnecessary unfoldings reduces heap usage - We are changing uniques, so if we didn't discard unfoldings/rules we'd have to substitute in them HOWEVER, we want to preserve evaluated-ness; see Note [Preserve evaluated-ness in CorePrep] Note [Preserve evaluated-ness in CorePrep] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We want to preserve the evaluated-ness of each binder (via evaldUnfolding) for two reasons * In the code generator if we have case x of y { Red -> e1; DEFAULT -> y } we can return 'y' rather than entering it, if we know it is evaluated (Trac #14626) * In the DataToTag magic (in CorePrep itself) we rely on evaluated-ness. See Note Note [dataToTag magic]. -} }}} I can also clearly see that in the code we don't distinguish exported from non-exported, we just zap all unfoldings (see `cpCloneBndrs` and `zapUnfolding`). So it seems to me like we may have to collect cost centers before or during CorePrep. I vaguely remember discussing this in the meeting and one of the arguments against this was that `CorePrep` is already complex enough so if possible it'd be nice to avoid making it even more complex. Are there any other reasons for not doing this in CorePrep? Can we maybe implement a pass before CorePrep just for cost center collection? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/5889#comment:29 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler