CompilerDevTools: add proof of concept for caching runtime calls#57193
Merged
Keno merged 10 commits intoJuliaLang:masterfrom Feb 28, 2025
Merged
CompilerDevTools: add proof of concept for caching runtime calls#57193Keno merged 10 commits intoJuliaLang:masterfrom
Keno merged 10 commits intoJuliaLang:masterfrom
Conversation
Member
Author
Keno
reviewed
Jan 29, 2025
Keno
reviewed
Jan 29, 2025
Keno
reviewed
Jan 29, 2025
Member
|
Some concrete comments, but this is largely what I had in mind, yes. |
Member
|
After many years of maintaining Cassette I distinctly dislike the approach to propagate the compiler through the IR. That's why in #52964 I approached this from the "what if they compiler was a scoped-value" perspective. I could rebase #52964 if there is interest (beyond myself) in exploring that alternative approach. |
Member
|
This specific utility is just for testing compiler changes (and exercising the caching and foreign CodeInstance APIs) without prejudice to having, more general mechanism, for compiler switches. |
Member
Author
Keno
pushed a commit
that referenced
this pull request
Feb 17, 2025
…egen cache (#57272) Implements a way to add `CodeInstance`s compiled by external interpreters to JIT, such that they become legal targets for `invoke` calls. Based on a design proposed by @Keno, the `AbstractInterpreter` interface is extended to support providing a codegen cache that is filled during inference for future use with `add_codeinsts_to_jit!`. This allows `invoke(f, ::CodeInstance, args...)` to work on external interpreters, which is currently failing on `master` (see #57193). --------- Co-authored-by: Cédric Belmant <cedric.belmant@juliahub.com>
Member
|
Should be rebasable now that #57272 is merged. |
vtjnash
reviewed
Feb 18, 2025
…ch 'master' of github.com:JuliaLang/julia into compiler-dev-tools
KristofferC
pushed a commit
that referenced
this pull request
Mar 31, 2025
…egen cache (#57272) Implements a way to add `CodeInstance`s compiled by external interpreters to JIT, such that they become legal targets for `invoke` calls. Based on a design proposed by @Keno, the `AbstractInterpreter` interface is extended to support providing a codegen cache that is filled during inference for future use with `add_codeinsts_to_jit!`. This allows `invoke(f, ::CodeInstance, args...)` to work on external interpreters, which is currently failing on `master` (see #57193). --------- Co-authored-by: Cédric Belmant <cedric.belmant@juliahub.com> (cherry picked from commit 9d2e9ed)
KristofferC
pushed a commit
that referenced
this pull request
Mar 31, 2025
…egen cache (#57272) Implements a way to add `CodeInstance`s compiled by external interpreters to JIT, such that they become legal targets for `invoke` calls. Based on a design proposed by @Keno, the `AbstractInterpreter` interface is extended to support providing a codegen cache that is filled during inference for future use with `add_codeinsts_to_jit!`. This allows `invoke(f, ::CodeInstance, args...)` to work on external interpreters, which is currently failing on `master` (see #57193). --------- Co-authored-by: Cédric Belmant <cedric.belmant@juliahub.com> (cherry picked from commit 9d2e9ed)
serenity4
added a commit
to serenity4/julia
that referenced
this pull request
May 1, 2025
…egen cache (JuliaLang#57272) Implements a way to add `CodeInstance`s compiled by external interpreters to JIT, such that they become legal targets for `invoke` calls. Based on a design proposed by @Keno, the `AbstractInterpreter` interface is extended to support providing a codegen cache that is filled during inference for future use with `add_codeinsts_to_jit!`. This allows `invoke(f, ::CodeInstance, args...)` to work on external interpreters, which is currently failing on `master` (see JuliaLang#57193). --------- Co-authored-by: Cédric Belmant <cedric.belmant@juliahub.com>
serenity4
added a commit
to serenity4/julia
that referenced
this pull request
May 1, 2025
…iaLang#57193) This PR leverages new capabilities that have been implemented in JuliaLang#56660 to also support caching methods for runtime calls under a custom `AbstractInterpreter`. In my understanding, the idea is that when executing code compiled with a custom `AbstractInterpreter`, only methods that can be compiled ahead of execution will be cached, because dynamic calls requiring runtime compilation will not have enough context to know which interpreter and cache to use. They will instead use the native interpreter and cache. This sample package demonstrates a way to ensure that runtime calls go through an entry point (`with_new_compiler`) that provides the context required to use the right cache and interpreter for subsequent compilation. I'd be happy to get feedback on the logic used to redirect runtime calls to `with_new_compiler`. Overloading `optimize(::SplitCacheInterp)` seemed the most convenient (right after that, the `IRCode` gets converted to a `CodeInfo`), but perhaps there might be a better place for it. --------- Co-authored-by: Cédric Belmant <cedric.belmant@juliahub.com>
serenity4
added a commit
to serenity4/julia
that referenced
this pull request
May 1, 2025
…ze` (JuliaLang#57640) As a follow-up to JuliaLang#57193 now that JuliaLang#57375 is merged. --------- Co-authored-by: Cédric Belmant <cedric.belmant@juliahub.com>
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
4 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.
This PR leverages new capabilities that have been implemented in #56660 to also support caching methods for runtime calls under a custom
AbstractInterpreter.In my understanding, the idea is that when executing code compiled with a custom
AbstractInterpreter, only methods that can be compiled ahead of execution will be cached, because dynamic calls requiring runtime compilation will not have enough context to know which interpreter and cache to use. They will instead use the native interpreter and cache.This sample package demonstrates a way to ensure that runtime calls go through an entry point (
with_new_compiler) that provides the context required to use the right cache and interpreter for subsequent compilation.I'd be happy to get feedback on the logic used to redirect runtime calls to
with_new_compiler. Overloadingoptimize(::SplitCacheInterp)seemed the most convenient (right after that, theIRCodegets converted to aCodeInfo), but perhaps there might be a better place for it.