StaticCompiler upgraded to Julia v1.11 #174
Conversation
|
Great to have this running on 1.11! I'll merge if no objections. While it looks like there may still be a few more issues to track down in the integration tests, this is more green than we've seen in CI for quite a while! |
There was a problem hiding this comment.
This looks really great. Thank you for taking this on!
I think it probably doesn't make sense to try and have so many if version(...) checks in here, and we should just increase our version support bounds.
If people aren't able to upgrade to newer versions of julia or GPUCompiler, they will get stuck with older versions of StaticCompiler which is fine.
Also, the pkgversion function was added in v1.9, so using it will break the v1.8 tests.
Since v1.10 is the current julia LTS, I say we drop support for v1.8 and 1.9, and drop support for GPUCompiler < 1.5
That should make this simpler and hopefully more robust too.
| @static if VERSION < v"1.9" | ||
| obj, _ = GPUCompiler.emit_asm(fakejob, mod; strip=strip_asm, validate=false, format=LLVM.API.LLVMObjectFile) | ||
| obj | ||
| else | ||
| @static if pkgversion(GPUCompiler) < v"1.3.0" | ||
| obj, _ = GPUCompiler.emit_asm(fakejob, mod; strip=strip_asm, validate=false, format=LLVM.API.LLVMObjectFile) | ||
| else | ||
| obj, _ = GPUCompiler.emit_asm(fakejob, mod, LLVM.API.LLVMObjectFile) | ||
| end | ||
| end | ||
| obj |
There was a problem hiding this comment.
It seems that the new way to handle kwargs like strip and validate is GPUCompierConfig: JuliaGPU/GPUCompiler.jl#668
There was a problem hiding this comment.
Indeed, GPUCompiler has changed significantly between versions 0.x and 1.x.
Supporting both versions requires considerable effort, and dropping support for older versions would make maintenance much smoother.
| using GPUCompiler: | ||
| @safe_debug, AbstractCompilerParams, CodeCache, CompilerJob, methodinstance | ||
| @safe_debug, AbstractCompilerParams, CompilerJob, methodinstance, CodeInstance, inference_params, optimization_params, get_inference_world |
There was a problem hiding this comment.
I think it'd be better to import some of this stuff from Core.Compiler where it's defined rather than `GPUCompiler.
There was a problem hiding this comment.
Unfortunately, Core.Compiler is an internal API and not guaranteed to be stable or long-term supported.
Since all the compilation-related data originates from GPUCompiler, I believe it's better to import the necessary functionality from GPUCompiler rather than relying directly on Core.Compiler.
There was a problem hiding this comment.
Those functions and types are not part of the public interface of GPUCompiler either. By importing them from GPUCompiler, you're relying on GPUCompiler internals and Core.Compiler internals. By importing those names out of GPUCompiler, you make it more vulnerable to instability, not less.
| # abstractarray.jl | ||
| @device_override @noinline Base.throw_boundserror(A, I) = | ||
| @print_and_throw c"Out-of-bounds array access" | ||
| # abstractarray.jl | ||
| # Base.throw_boundserror is removed since v1.11 | ||
| if VERSION < v"1.11" | ||
| @device_override @noinline Base.throw_boundserror(A, I) = | ||
| @print_and_throw c"Out-of-bounds array access" | ||
| end |
There was a problem hiding this comment.
Base.throw_boundserror definitely was not removed in v1.11.
There was a problem hiding this comment.
In my tests, Bumper v0.6.0 fails to work with Julia v1.11 due to its attempt to override Base.throw_boundserror.
However, when switching to Bumper v0.7.0, everything works smoothly, as this version uses a different backend (UnsafeArrays).
Although the throw_boundserror function still exists in Julia v1.11, its definition has been moved from abstractarray.jl to essential.jl, which might indicate that it has been made non-overridable.
There was a problem hiding this comment.
Weird. Let's just drop Bumper 0.6 support then and put a compat bound with Bumper v0.7 as the minimum.
Please restore the device overrride for the boundserror in v1.11+, we need that.
There was a problem hiding this comment.
Unfortunately, Bumper v0.6 is required by StaticTools.jl. However, I believe that updating Bumper in StaticTools will not affect its functionality. Currently, I’m helping the developers with some new functionality for StaticTools.
There was a problem hiding this comment.
The version of StaticTools that we registered yesterday (0.8.11) should support Bumper v0.7 since the PR right before yours bumped the compat bounds on Bumper
| @@ -18,11 +18,11 @@ StaticTools = "86c06d3c-3f03-46de-9781-57580aa96d0a" | |||
|
|
|||
| [compat] | |||
| CodeInfoTools = "0.3" | |||
| GPUCompiler = "0.21, 0.22, 0.23, 0.24, 0.25, 0.26" | |||
| LLVM = "6" | |||
| GPUCompiler = "0.21, 0.22, 0.23, 0.24, 0.25, 0.26, 1.5, 1" | |||
There was a problem hiding this comment.
I think the 1 shouldn't be here, just 1.5
Dear all,
After repeated testing, I’m glad to report that StaticCompiler.jl now works with Julia v1.11.
If you run into any issues, feel free to leave a comment or open an issue.
Upcoming: StaticLLVM.jl
I’m also working on a new package called StaticLLVM.jl, which builds on the infrastructure of StaticCompiler.jl and StaticTools.jl. It is designed to assist with processing LLVM IR for static compilation workflows.
If you have any feature suggestions or specific needs, feel free to let me know!
Thanks!
Kylin