Skip to content

Evaluate impact of more cross-module specialization by default

Motivation

Currently, GHC will not do any cross-module specialization "by default", even if the unfolding is available. It must be given explicit permission to do so via -fspecialize-aggressively or an INLINABLE/INLINE pragma on the imported binding. In any of these cases, it will do the specialization regardless of the unfolding size.

Proposal

It might be useful to (re?)evaluate the impact of doing more cross-module specialization, potentially reusing the -funfolding-use-threshold as a heuristic. I'm imagining a -fspecialize-carefully flag, where the decision to specialize would be more like:

  • Is -fspecialize-aggressively enabled, or is it INLINE{ABLE}? If so, specialize, otherwise,
  • Is -fspecialize-carefully enabled? If so, specialize if the unfolding is under unfoldingUseThreshold * X, where X is some scaling factor that can be set by another flag.

There's a good chance it would just grow code size/compilation cost without much performance benefit, but the results for various values of that scaling factor could be interesting nonetheless.

Edited by Finley McIlwaine
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information