[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 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