define Core.Closure and make compiler-generated closures subtype of it
#56928
Conversation
Performance issues related to code containing closures are frequently discussed (e.g., #15276, #56561). Several approaches can be considered to address this problem, one of which involves re-inferring code containing closures (#56687). To implement this idea, it is necessary to determine whether a given piece of code includes a closure. However, there is currently no explicit mechanism for making this determination (although there are some code that checks whether the function name contains `"#"` for this purpose, but this is an ad hoc solution). To address this, this commit lays the foundation for future optimizations targeting closures by defining closure functions as a subtype of the new type `Core.Closure <: Function`. This change allows the optimizer to apply targeted optimizations to code containing calls to functions that are subtype of `Core.Closure`.
|
Is it possible to disallow manual subtyping of |
As far as I understand, the initial idea with #56687 was to apply post-optimization inference to all code, but now this is being restricted to merely the compiler-generated closures. May I ask why, out of curiosity? |
It might be possible, but what is the purpose of doing so?
The re-inference implemented in #56687 can be applied to any code but is not executed for all code. It is only performed when the optimizer could derive new type information. For code containing closures, this typically requires either inlining the closure or performing inter-procedural alias analysis. In any case, applying re-inference to all code would incur significant latency costs, so it must be performed selectively. |
If the type is intended as a surefire way for the compiler to know that the closure object came from itself earlier in the compilation pipeline, i.e. that instances of it uphold the invariants concrete subtypes of |
|
What is the expected benefit of this, over the existing definition of a closure: |
There are no limits on what a |
I would like to apply a special inline cost to closures to enable aggressive SROA and optimize away closure constructs. And the existing definition applies to all functors, but the issue I aim to address is specific to the compiler-generated closures. |
I'm not talking about what a closure can do in the computational sense. I understand that For example, is it allowed to define |
Performance issues related to code containing closures are frequently discussed (e.g., #15276, #56561). Several approaches can be considered to address this problem, one of which involves re-inferring code containing closures (#56687). To implement this idea, it is necessary to determine whether a given piece of code includes a closure. However, there is currently no explicit mechanism for making this determination (although there are some code that checks whether the function name contains
"#"for this purpose, but this is an ad hoc solution).To address this, this commit lays the foundation for future optimizations targeting closures by defining closure functions as a subtype of the new type
Core.Closure <: Function. This change allows the optimizer to apply targeted optimizations to code containing calls to functions that are subtype ofCore.Closure.