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

| 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@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
participants (1)
-
Simon Peyton Jones