Eliminate per-call closure for InlineIfLambda partial applications - #20487
Open
T-Gro wants to merge 1 commit into
Open
Eliminate per-call closure for InlineIfLambda partial applications#20487T-Gro wants to merge 1 commit into
T-Gro wants to merge 1 commit into
Conversation
Contributor
❗ Release notes requiredYou can open this PR in browser to add release notes: open in github.dev
|
T-Gro
force-pushed
the
t-gro-optimizer-etaexpand-inlineiflambda-spike
branch
2 times, most recently
from
September 8, 2026 11:00
f516ecd to
b6b95a3
Compare
github-actions
Bot
added
the
AI-Tooling-Check-Bypassed
…remove closures When a partial application of a module-level function is passed to an [<InlineIfLambda>] parameter (e.g. `xs |> Option.map (f a b)`), a non-trivial captured argument (a field read, a call) forced a per-call FSharpFunc closure: the optimizer only beta-reduces a lambda-valued argument whose optimization info is a syntactic lambda, and a surviving let for the effectful capture keeps the argument's info UnknownValue. The InlineIfLambda argument binding is now eta-expanded to a lambda with its captured evaluations floated above the binding, so the parameter's uses beta-reduce and the closure is eliminated. Generalizes the single call site hand-fixed in #20426. - Recognition is an EtaFloatableValLet active pattern; the float is a small floatEtaCaptures helper. Reuses TryEtaExpandUnderAppliedValApp (shared with LowerCalls). - Captured arguments are evaluated exactly once, in left-to-right order. - Fires only for [<InlineIfLambda>] parameter bindings, so it never eta-floats a module-level value definition or a partial application inside an SRTP inline-member body, which cross-project measurement showed can multiply closures. No closure-count change in FSharp.Core, FSharpPlus, IcedTasks or the compiler test suite. - Self-compiling FSharp.Compiler.Service.dll: FSharpFunc closure types 16224 -> 16203 (-21). Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 42beb491-2421-4b80-9586-e03454f76524
T-Gro
force-pushed
the
t-gro-optimizer-etaexpand-inlineiflambda-spike
branch
from
September 9, 2026 08:30
b6b95a3 to
a8eeb1f
Compare
T-Gro
enabled auto-merge (squash)
September 9, 2026 10:31
abonie
reviewed
Sep 10, 2026
| * Make Entity's adhoc members list lazy ([PR #20286](https://github.com/dotnet/fsharp/pull/20286/changes)) | ||
| * Constraint solver: `TryD` is now `inline` with `[<InlineIfLambda>]` on its always-run continuation, so the argument closures are no longer allocated at the (very hot) constraint-solver call sites; `IgnoreFailedMemberConstraintResolution` is `inline` so its forwarded continuation stays a literal. ([PR #20367](https://github.com/dotnet/fsharp/pull/20367)) | ||
| * `DelayedILModuleReader` no longer boxes its cached `ILModuleReader` on every read: the field is typed `ILModuleReader | null` and matched directly. ([PR #20413](https://github.com/dotnet/fsharp/pull/20413)) | ||
| * Optimizer: passing a partial application of a module-level function to an `[<InlineIfLambda>]` parameter (e.g. `xs |> Option.map (f a b)`) no longer allocates a per-call `FSharpFunc` closure when a captured argument is non-trivial (a field read, a call). Under optimization the argument is eta-expanded to a lambda with its captured evaluations floated above the binding, so the parameter's uses beta-reduce and the closure is eliminated. Captured arguments are still evaluated exactly once, in their original left-to-right order, and the binding keeps its sequence point. ([PR #20487](https://github.com/dotnet/fsharp/pull/20487)) |
Member
There was a problem hiding this comment.
Partial applications of inline/SRTP functions and curried members can still allocate closures - should be reflected in the release note?
abonie
approved these changes
Sep 10, 2026
github-project-automation
Bot
moved this from New
to In Progress
in F# Compiler and Tooling
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Passing a partial application of a module-level function to an
[<InlineIfLambda>]parameter allocated anFSharpFuncclosure per call whenever a captured argument was non-trivial (a field read, a call): the optimizer only beta-reduces a lambda-valued argument whose optimization info is a syntactic lambda, and a partial application carriesUnknownValue. The argument is now eta-expanded to a lambda with its captured evaluations floated above the binding, so the parameter's uses beta-reduce and the closure is eliminated. Captured arguments are still evaluated exactly once, in order. This generalizes the single call site hand-fixed in #20426 to every such site.Self-compiling
FSharp.Compiler.Service.dll(no closure-count change in FSharp.Core, FSharpPlus, IcedTasks or the compiler test suite):FSharpFuncclosure display-classesThe 21 eliminated closures include
memberInfoR@1696— the exact one #20426 removes by hand.