Expose native_code's jl_sysimg_gvars. #58423
Merged
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.
#57010 overhauled how global variables are initialized in code, breaking GPUCompiler.jl. After talking to @vtjnash, we are apparently supposed to use
jl_get_llvm_gvs
now to get the Julia memory location of a global variable (for a binding or constant value), however, the elements in there don't exactly correspond to the global variables in the module (not all module globals are "managed" by Julia, and the order is different).To make GPUCompiler.jl work again, here I propose renaming
jl_get_llvm_gvs
tojl_get_llvm_gv_inits
, and makingjl_get_llvm_gvs
instead return the list of the managed global variables, making it possible to perform the global variable initialization that was done by Julia before using something like: