Andreas Klebinger pushed to branch wip/apk/expose-overloaded-unfoldings at Glasgow Haskell Compiler / GHC Commits: 1077867a by Andreas Klebinger at 2026-09-30T16:05:13+00:00 Enable -fexpose-overloaded-unfoldings by default when optimizations are on. I also made the -fexpose-*-unfoldings flags optimization flags rather than codeGen flags. This was needed to fix a test and is the correct place for them. Performance numbers: In general this averages out to ~1% more file size across the GHC build. Compiler allocations grow by 0.14% on nofib as the compiler needs to deal with more available unfoldings. On the cabal test it's awash. With some configurations getting slightly faster, some slightly slower. It's all in the +/- 0.2% range. On nofib itself we produce exactly the same code. Which is expected, as it doesn't use -fspecialize-aggresively anywhere afaik which is needed to take advantage of cross module specialization. Fixes #13090 ------------------------- Metric Increase: LinkableUsage01 LinkableUsage02 MultiLayerModulesTH_Make MultiLayerModulesTH_OneShot T21839c T24471 hard_hole_fits ------------------------- - - - - - 6 changed files: - + changelog.d/T13090-expose-overloaded-unfoldings - compiler/GHC/Driver/DynFlags.hs - compiler/GHC/Driver/Flags.hs - compiler/GHC/Iface/Tidy.hs - docs/users_guide/using-optimisation.rst - testsuite/tests/dmdanal/should_compile/T23398.stderr Changes: ===================================== changelog.d/T13090-expose-overloaded-unfoldings ===================================== @@ -0,0 +1,6 @@ +section: compiler +issues: #13090 +mrs: !16684 +synopsis: + Enable :ghc-flag:`-fexpose-overloaded-unfoldings` by default with :ghc-flag:`-O` or higher. + ===================================== compiler/GHC/Driver/DynFlags.hs ===================================== @@ -1337,6 +1337,7 @@ optLevelFlags -- see Note [Documenting optimisation flags] , ([1,2], Opt_Specialise) , ([1,2], Opt_PolymorphicSpecialisation) -- Now on by default (#23559) , ([1,2], Opt_CrossModuleSpecialise) + , ([1,2], Opt_ExposeOverloadedUnfoldings) -- See Note [Exposing overloaded functions] in GHC.Iface.Tidy , ([1,2], Opt_InlineGenerics) , ([1,2], Opt_Strictness) , ([1,2], Opt_UnboxSmallStrictFields) ===================================== compiler/GHC/Driver/Flags.hs ===================================== @@ -971,6 +971,8 @@ optimisationFlags = EnumSet.fromList , Opt_SolveConstantDicts , Opt_SpecEval , Opt_SpecEvalDictFun + , Opt_ExposeAllUnfoldings + , Opt_ExposeOverloadedUnfoldings ] -- | The set of flags which affect code generation and can change a program's @@ -1001,8 +1003,6 @@ codeGenFlags = EnumSet.fromList , Opt_OmitYields -- Flags that affect generated code - , Opt_ExposeAllUnfoldings - , Opt_ExposeOverloadedUnfoldings , Opt_NoTypeableBinds , Opt_NoBuiltinRules , Opt_NoBignumRules ===================================== compiler/GHC/Iface/Tidy.hs ===================================== @@ -806,8 +806,19 @@ anyway we allow for some false positives and simply expose all functions which have a constraint. This means we might expose more unhelpful unfoldings. But it seems like the better choice. -Currently this option is off by default and has to be enabled manually. But -we might change this in the future. +We enable the flag by default with -O/O2 to allow users to opt into specialization +at call sites. We do not enable -fspecialize-aggressively. See also #13090. + +In terms of performance impact the cost is very modest: +On GHC and it's boot libraries overall enabling this flag increases overall disk +space used by ~1%. With a highly variant distribution across various .hi files. +In terms of compile times the overhead is low enough to be hard to measure, but +seemed to be less than 0.2% if anything at all. + +It seems tempting to do the same for -fspecialize-aggressively, but that comes in +at a hefty 20% compile time overhead. So we only provide the unfoldings and leave +the choice of how much specialization to enable up to the user. + -} {- ===================================== docs/users_guide/using-optimisation.rst ===================================== @@ -624,10 +624,10 @@ as such you shouldn't need to set any of them explicitly. A flag :reverse: -fno-expose-overloaded-unfoldings :category: - :default: off + :default: -O and above :since: 9.12.1 - This experimental flag is a slightly less heavy weight alternative + This flag is a slightly less heavy weight alternative to :ghc-flag:`-fexpose-all-unfoldings`. Instead of exposing all functions it exposes only those functions which ===================================== testsuite/tests/dmdanal/should_compile/T23398.stderr ===================================== @@ -40,7 +40,9 @@ T23398.$wbar [InlPrag=[2], Occ=LoopBreaker] [GblId[StrictWorker([~, !])], Arity=4, Str=<L><SP(A,SC(S,L),A)><1L><L>, - Unf=OtherCon []] + Unf=Unf{Src=<vanilla>, TopLvl=True, + Value=True, ConLike=True, WorkFree=True, Expandable=True, + Guidance=IF_ARGS [0 90 60 0] 91 70}] T23398.$wbar = \ (@a) (@b) View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/1077867aa7ee380599145d4634198b13... -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/1077867aa7ee380599145d4634198b13... You're receiving this email because of your account on gitlab.haskell.org. Manage all notifications: https://gitlab.haskell.org/-/profile/notifications | Help: https://gitlab.haskell.org/help