JuliaGPU / JuliaGPU/GPUCompiler.jl
GPURuntime compilation can "embedd" julia runtime values
- Dominant language
- Julia
- Stars
- 187
- Forks
- 68
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 28
Description
@pxl-th reported on slack the following odd behavior.
During first execution exception reporting on AMDGPU (HIP rewrite) works fine, on the second one it
doesn't and the host code that tries to read the exception from the buffer sees a pointer to a type from the previous Julia session.
This could happen with Types/Symbols/... the works.
This is due to the fact that the runtime saves it bitcode to disk and re-uses it between sessions, so our usual assumptions of embedding
host pointers is fine, is no longer okay. This becomes even more relevant under generalized caching. (x-ref: #351 )
I see two paths forward:
1. We fix imaging mode and use it for code that will be cached. The current problem with imaging mode is that we are missing a mapping from GV to JL value. (This is an issue for StaticCompiler as well currently)
2. We do the Enzyme / StaticCompiler hack for the runtime. Find pointer values, rewrite them to GVs... carry on.
The former will likely need changes to Julia base, and the latter is "proven" but stupid.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reproducing the AMDGPU/HIP exception-reporting behavior across two Julia sessions and trace how cached runtime bitcode preserves Julia values. Compare the proposed imaging-mode and Enzyme/StaticCompiler approaches; done means cached code no longer embeds pointers or values from a previous session.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- julia
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100