Duplicate exported functions?
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.
Trac metadata
| Trac field | Value |
|---|---|
| Version | 8.0.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |
