use compilesig_invokes=false - #908
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #908 +/- ##
==========================================
+ Coverage 85.41% 85.64% +0.22%
==========================================
Files 29 29
Lines 5582 5578 -4
==========================================
+ Hits 4768 4777 +9
+ Misses 814 801 -13 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
| optimization_params(@nospecialize(job::CompilerJob)) = | ||
| CC.OptimizationParams(; compilesig_invokes=false) |
There was a problem hiding this comment.
We might have to make this configurable And how does this differ from Core.Compiler.infer_compilation_signature?
There was a problem hiding this comment.
optimization_params is already an overridable hook, no?
And I'm not familiar with the other flag. According to Astra:
Difference from
infer_compilation_signature: that flag asks inference to also infer the widened compilation signature.compilesig_invokes=falseinstead prevents the optimizer from redirecting invokes to that wider specialization. Inferring the wider signature can address a missing cache entry, but does not preserve the concrete argument types needed for static dispatch.
Use a null-returning allocator when the runtime module does not define malloc. Allocation attempts then follow the existing out-of-memory path, while kernels with allocations confined to untaken error paths can still compile and execute. This handles the boxed DomainError paths in exponent on oneAPI (#906). Back-end-provided allocators retain precedence.
Disable compilesig_invokes so noinline vararg calls retain their inferred argument types instead of targeting widened compilation signatures that may not be cached. This is needed for the multidimensional bounds-error paths introduced in Julia 1.14. Keep the existing optimization_params hook for back-end overrides. Inferring compilation signatures is a different policy: it populates the wider specializations without preserving the precision of the original call.
Use an opaque allocator in the Bool conversion regression so LLVM retains the heap-reference stores that exposed #904. The constant-null test allocator otherwise removes those stores before AIR lowering.
f898afd to
da96c50
Compare
3 participants
Re-lands #899. Will need fixed for Metal.jl (#904), oneAPI.jl (#906), and CI improvements to flush this out early.