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

[Simon Peyton Jones]

|  Simon, we were wrong about CorePrep not dropping unfoldings for exported
| ids, it really drops all unfoldings.

I'd forgotten that.  Notes are so useful!

|  Are there any other reasons for not doing this in CorePrep? Can we maybe
| implement a pass before CorePrep just for cost center collection?

Currently CorePrep is just in a unique-supply monad.  But I guess you could add a writer monad to allow us to collect cost centres.  That should not be hard.

Alternatively, a separate pass (run only if we have profiling).   I don’t feel strongly.  A separate pass run always seems overkill somehow.

Simon


| -----Original Message-----
| From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf Of
| GHC
| Sent: 17 January 2018 06:54
| Subject: 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 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:
| <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.hask
| ell.org%2Ftrac%2Fghc%2Fticket%2F5889%23comment%3A29&data=02%7C01%7Csimonp
| j%40microsoft.com%7C4c0906a7bcde47e7d7ac08d55d77108f%7C72f988bf86f141af91
| ab2d7cd011db47%7C1%7C0%7C636517688316807916&sdata=5eSk5giuvhClD%2BxskYvyc
| f9qqTyYn%2Fwy3%2FxSuDoXMQA%3D&reserved=0>
| GHC
| <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.hask
| ell.org%2Fghc%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C4c0906a7bcde47e
| 7d7ac08d55d77108f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365176883
| 16817923&sdata=aandvbx2KYXpNrhNPodNIt%2FtxpY2yT4YytP0PTyIkDQ%3D&reserved=
| 0>
| The Glasgow Haskell Compiler