Add the inline-threshold flag for setting inliner aggressiveness #6982

zliu41 · 2025-03-26T20:22:01Z

inline-threshold = x means: callsite inlining is allowed to proceed as long as the new size is no more than original size plus x. So the higher x is, the more aggressive the inliner inlines. Currently the new size must be no more than the original size (i.e., equivalent to x = 0), which is too conservative.

I experimented with several values between 4 and 20, and found that 5 works the best overall, so I'm setting 5 as the default.

…nline-threshold

Unisay · 2025-03-28T09:21:51Z

doc/docusaurus/docs/delve-deeper/plinth-compiler-options.md

@@ -34,6 +32,7 @@ For each boolean option, you can add a `no-` prefix to switch it off, such as `n
 |`dump-uplc`|Bool|False|Dump Untyped Plutus Core|
 |`inline-constants`|Bool|True|Always inline constants. Inlining constants always reduces script costs slightly, but may increase script sizes if a large constant is used more than once. Implied by `no-conservative-optimisation`.|
 |`inline-fix`|Bool|True|Always inline fixed point combinators. This is generally preferable as it often enables further optimization, though it may increase script size.|
+|`inline-threshold`|Int|5|Set inliner aggressiveness. 0 means it avoids making the program bigger. Higher values make the inliner more willing to inline.|


Initially, judging on the option name only, I thought that "inline-threshold" is maximum value of some metric, (e.g. maximum program size, or maximum number of terms etc.). This line shows me that its a "level" of inliner aggressiveness.

I propose to name the option either inline-force or inline-level

https://g.co/gemini/share/f8e59770d1db

Update: after reading the rest of the code I realize that my initial intuition was right, eventually this value is used as a maximum program increase in Size that inliner accepts. Its the description that misled me. I also understand that a "maximum program increase in Size" can be seen as inliner's aggressiveness... indirectly. I mean the description is not "what the option value is" rather "what is an effect of this value".

I agree this should also say that it may increase the program's size by, at maximum, the value provided as the inline-threshold.

eventually this value is used as a maximum program increase in Size

As @ana-pantilie said in the other comment, this is not the case. I'll rename it to inline-callsite-growth, which aligns with the GCC flag inline-unit-growth.

Unisay · 2025-03-28T09:39:00Z

plutus-core/untyped-plutus-core/src/UntypedPlutusCore/Simplify/Opts.hs

@@ -20,6 +21,7 @@ data SimplifyOpts name a = SimplifyOpts
  , _soConservativeOpts        :: Bool
  , _soInlineHints             :: InlineHints name a
  , _soInlineConstants         :: Bool
+  , _soInlineThreshold         :: Int


I'd use Size newtype (from the PlutusCore.Size) because this is what threshold is converted to in the end.

Sounds reasonable.

Unisay · 2025-03-28T09:40:33Z

plutus-core/plutus-ir/src/PlutusIR/Transform/Inline/CallSiteInline.hs

-              let -- Inline only if the size is no bigger than not inlining.
-                  sizeIsOk = termSize inlined <= processedTSize
+              let -- Inline only if the size is no bigger than not inlining plus threshold.
+                  sizeIsOk = termSize inlined <= processedTSize + fromIntegral (max 0 thresh)


No fromIntegral would be needed if thresh has type Size (from the PlutusCore.Size module.

Unisay · 2025-03-28T09:52:57Z

plutus-core/plutus-ir/src/PlutusIR/Compiler/Types.hs

@@ -95,6 +95,7 @@ data CompilationOpts a = CompilationOpts {
    , _coInlineHints                    :: InlineHints PLC.Name (Provenance a)
    , _coInlineConstants                :: Bool
    , _coInlineFix                      :: Bool
+    , _coInlineThreshold                :: Int


I'd really ❤️ to use the Size newtype here.

Unisay · 2025-03-28T09:54:42Z

plutus-core/plutus-ir/test/PlutusIR/Transform/Inline/Tests.hs

@@ -76,4 +76,4 @@ prop_inline biVariant =
  withMaxSuccess numTestsForPassProp $
    testPassProp
      runQuote
-      $ \tc -> inlinePassSC True tc def (def {_biSemanticsVariant = biVariant})
+      $ \tc -> inlinePassSC 0 True tc def (def {_biSemanticsVariant = biVariant})


Another benefit that using the Size newtype gives is that this magic 0 could be less magical:

Suggested change

$ \tc -> inlinePassSC 0 True tc def (def {_biSemanticsVariant = biVariant})

$ \tc -> inlinePassSC (Size 0) True tc def (def {_biSemanticsVariant = biVariant})

ana-pantilie

It looks like it gives good results in practice, or at least on the test cases we have in our repo, but I think that the description makes it sound deceptively safe, see my comments.

...no-constitution/test/Cardano/Constitution/Validator/Data/GoldenTests/sorted.cbor.size.golden

ana-pantilie · 2025-03-28T10:27:04Z

doc/docusaurus/docs/delve-deeper/plinth-compiler-options.md

@@ -34,6 +32,7 @@ For each boolean option, you can add a `no-` prefix to switch it off, such as `n
 |`dump-uplc`|Bool|False|Dump Untyped Plutus Core|
 |`inline-constants`|Bool|True|Always inline constants. Inlining constants always reduces script costs slightly, but may increase script sizes if a large constant is used more than once. Implied by `no-conservative-optimisation`.|
 |`inline-fix`|Bool|True|Always inline fixed point combinators. This is generally preferable as it often enables further optimization, though it may increase script size.|
+|`inline-threshold`|Int|5|Set inliner aggressiveness. 0 means it avoids making the program bigger. Higher values make the inliner more willing to inline.|


I agree this should also say that it may increase the program's size by, at maximum, the value provided as the inline-threshold.

plutus-benchmark/nofib/test/9.6/clausify-F5.size.golden

ana-pantilie · 2025-03-28T10:38:18Z

plutus-core/untyped-plutus-core/src/UntypedPlutusCore/Transform/Inline.hs

-                -- Inline only if the size is no bigger than not inlining.
-                sizeIsOk = termSize fullyApplied <= termSize t
+                -- Inline only if the size is no bigger than not inlining plus threshold.
+                sizeIsOk = termSize fullyApplied <= termSize t + max 0 (fromIntegral thresh)


Hmm, so the size is local in the sense that it checks that the size didn't increase for each inline iteration by more than the amount.
I guess that it could lead to other optimisations being applied, therefore reducing the final size, or even potentially increasing the final size by more than the threshold! I would imagine that the worst case scenario is that the size increases by the threshold amount each iteration, so the final size increases by numIterations * threshold, this of course assumes that the other optimisations don't increase program size, or do they?

In any case, from the documentation my understanding was that the size threshold is global: after all inlining has been performed the final size of the program is no larger than originalSize + 5. At least, I think this needs to be clarified.

In any case, from the documentation my understanding was that the size threshold is global

I am intentionally not specifying in the documentation how the value of this flag translates to program size! Instead I'm simply saying "Higher values make the inliner more willing to inline". How do you propose modifying the documentation (without making it too verbose)?

I guess that it could lead to other optimisations being applied, therefore reducing the final size

It could also allows to remove the binding. See #6975.

Yes I agree it's tricky to explain without getting too technical. Either we could say what you just said, that it's not a direct equivalent of program size (but then, what is it?), or we could give a bit more information. Could we just mention that it specifies the maximum amount the program may increase in size per inline iteration? That, together with the idea of calling it as you suggested inline-callsite-growth should clear up the confusion. If there is slightly more space in the docs, maybe we could also say that it may eventually even decrease program size.

Add the inline-threshold flag for setting inliner aggressiveness

eaa7a56

zliu41 requested a review from a team March 26, 2025 20:22

zliu41 temporarily deployed to github-pages March 26, 2025 20:22 — with GitHub Actions Inactive

fix tests

d1d2f91

zliu41 temporarily deployed to github-pages March 26, 2025 21:24 — with GitHub Actions Inactive

fix tests

b1c7963

zliu41 temporarily deployed to github-pages March 26, 2025 23:02 — with GitHub Actions Inactive

Merge branch 'master' of github.com:IntersectMBO/plutus into zliu41/i…

eec3239

…nline-threshold

zliu41 temporarily deployed to github-pages March 27, 2025 14:58 — with GitHub Actions Inactive

Unisay reviewed Mar 28, 2025

View reviewed changes

ana-pantilie reviewed Mar 28, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add the inline-threshold flag for setting inliner aggressiveness #6982

Add the inline-threshold flag for setting inliner aggressiveness #6982

zliu41 commented Mar 26, 2025

Unisay Mar 28, 2025

Unisay Mar 28, 2025

ana-pantilie Mar 28, 2025

zliu41 Mar 29, 2025

Unisay Mar 28, 2025

zliu41 Mar 29, 2025

Unisay Mar 28, 2025

Unisay Mar 28, 2025

Unisay Mar 28, 2025

ana-pantilie left a comment

ana-pantilie Mar 28, 2025

ana-pantilie Mar 28, 2025

zliu41 Mar 29, 2025

ana-pantilie Mar 31, 2025 •

edited

Loading

	$ \tc -> inlinePassSC 0 True tc def (def {_biSemanticsVariant = biVariant})
	$ \tc -> inlinePassSC (Size 0) True tc def (def {_biSemanticsVariant = biVariant})

Add the inline-threshold flag for setting inliner aggressiveness #6982

Are you sure you want to change the base?

Add the inline-threshold flag for setting inliner aggressiveness #6982

Conversation

zliu41 commented Mar 26, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ana-pantilie left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ana-pantilie Mar 31, 2025 • edited Loading

Choose a reason for hiding this comment

ana-pantilie Mar 31, 2025 •

edited

Loading