JuliaGPU / JuliaGPU/GPUCompiler.jl

GPURuntime compilation can "embedd" julia runtime values

Open
#460 2 comments 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.