You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Wrapping an always-inline (or @transparent) call in a no-escape closure should have no impact on the generated SIL at -Onone.
In particular, the stdlib should be able to rely on
defer { _fixLifetime(x) }
to have identical behavior to a direct call to _fixLifetime, even at -Onone.
When a no-escape closure is called directly, as in `defer`, inlining it reduces code size. There's no way to mark the closure itself as always-inline, but that could be inferred from simple patterns. If each captured variable is directly passed to an always-inline function like _fixLifetime, the users certainly wants the closure to be inlined.
1. Recognize certain noescape closures patterns and mark them always-inline before mandatory inlining.
2. More generally recognize noescape closure patterns for inlining during or after MandatoryInlining. For example, a closure with only fix_lifetime instructions should be recognized as zero-cost, regardless of multiple callers. Furthermore, we may just want to inline all no-escape closures with only one caller.
The text was updated successfully, but these errors were encountered:
I don't think this is correct; it's that -Onone should inline defer. But I guess the only other noescape closures we have that you can inline at -Onone are the ones that are directly called, and that wouldn't do any harm.
The user (stdlib author in this case) needs a way to control Onone inlining. The non-defer case comes up if the closure is being passed through an inline-always call path. So always inlining no-escape
gives the user what they occasionally need without adding syntax
often incidentally improves Onone performance without hurting debugging
It can do harm; it can increase code size. But if I said that the rule could be "inline(always) applied to a function automatically applies to its closure arguments as well", you'd rightly point out that that has the exact same effect in practice.
Additional Detail from JIRA
md5: 35a9d025ccabb934e12da343f595ac7d
relates to:
Issue Description:
Wrapping an always-inline (or
@transparent
) call in a no-escape closure should have no impact on the generated SIL at-Onone
.In particular, the stdlib should be able to rely on
to have identical behavior to a direct call to
_fixLifetime
, even at -Onone.When a no-escape closure is called directly, as in `defer`, inlining it reduces code size. There's no way to mark the closure itself as always-inline, but that could be inferred from simple patterns. If each captured variable is directly passed to an always-inline function like _fixLifetime, the users certainly wants the closure to be inlined.
Example:
This could be done a couple different ways
1. Recognize certain noescape closures patterns and mark them always-inline before mandatory inlining.
2. More generally recognize noescape closure patterns for inlining during or after MandatoryInlining. For example, a closure with only fix_lifetime instructions should be recognized as zero-cost, regardless of multiple callers. Furthermore, we may just want to inline all no-escape closures with only one caller.
The text was updated successfully, but these errors were encountered: