[GHC] #12961: Duplicate exported functions?
GHC
ghc-devs at haskell.org
Sun Dec 11 17:15:26 UTC 2016
#12961: Duplicate exported functions?
-------------------------------------+-------------------------------------
Reporter: nomeata | Owner:
Type: task | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.0.1
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
In my paper on Call Arity, I wrote
> Unfortunately it also means that adding a top-level function to the
export list of the module can prevent Call Arity from eta-expanding it and
other functions in the module.
and a reviewer asked
> Why don’t you duplicate and specialize the function?
And that is an interesting question, which I don’t want to pursue at the
moment in detail, but note down.
Obviously, if the the function can be inlined in all uses in the current
module, we essentially do that already. But if not (for example, because
it is recursive), then this could indeed improve the performance of the
in-module uses.
The question is: Is it worth it?
Questions on the way:
Do we have more analyses like Call Arity that gather information form the
use sites, and that need to make pessimistic assumptions for exported
functions, or is it the only one?
In terms of final code size: Will CSE reliably undo the duplication of
possible large swathes of code if both copies of the function were
compiled identically?
Maybe instead of duplicating all exported functions opportunistically,
Call Arity could analyze them twice and only if it gets useful data from
the use-sites cause them to be duplicated.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12961>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list