Skip to content

Only demote unordered atomic loads and stores - #950

Open
maleadt wants to merge 2 commits into
tb/reject-reference-allocationsfrom
tb/remove-atomics-demotion
Open

maleadt wants to merge 2 commits into
tb/reject-reference-allocationsfrom
tb/remove-atomics-demotion

Conversation

@maleadt

@maleadt maleadt commented Sep 25, 2026 •

Copy link
Copy Markdown
Member

demote_atomics! (#904, #924, #927) turned every LLVM atomic load and store into a plain one on Metal and SPIR-V because Julia's GC orderings (unordered reference loads and stores, release type-tag stores) reached back-ends that cannot express them. This also silently weakened user atomics, such as UnsafeAtomics' load/store! and Atomix' get/set! on OpenCL, oneAPI, and POCL: the vendor compiler could hoist a spin-wait's atomic load.

#940 removes dead exception objects, and #949 rejects remaining allocations of objects that contain references, so the release type-tag stores no longer reach the back-ends. unordered loads of heap references still do when they don't involve an allocation, e.g. of a DataType field of an immutable struct, or of a reference to a mutable object, passed by reference to a @noinline function. Those fail SPIR-V validation with the Khronos translator, and Metal rejects them once it lowers LLVM atomics (#942), as they are pointer-sized and outside device and threadgroup memory. So this PR narrows the demotion to unordered loads and stores, which only promise not to tear, and leaves atomics with other orderings alone.

With the whole stack, test results are unchanged (see #949). The KernelAbstractions POCL test suite has 11 UnsafeAtomics/Atomix atomics that are no longer demoted.

Reflection (code_llvm, code_native) does not validate IR, so an object with references can still reach the back-end with its GC orderings, as can other invalid IR.

@codecov

codecov Bot commented Sep 25, 2026 •

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.97%. Comparing base (e5adcf7) to head (971e6ae).

Additional details and impacted files
@@                         Coverage Diff                         @@
##           tb/reject-reference-allocations     #950      +/-   ##
===================================================================
- Coverage                            86.99%   86.97%   -0.03%     
===================================================================
  Files                                   29       29              
  Lines                                 5915     5904      -11     
===================================================================
- Hits                                  5146     5135      -11     
  Misses                                 769      769              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@maleadt
maleadt force-pushed the tb/remove-atomics-demotion branch from 78d617d to 971e6ae Compare September 28, 2026 16:52
`demote_atomics!` turned every LLVM atomic load and store into a plain one on Metal and
SPIR-V to accommodate Julia's GC orderings. Dead exception objects are now removed, and
remaining allocations of objects that contain references are rejected, so those orderings
no longer reach the back-ends. The demotion therefore only weakened user atomics
(UnsafeAtomics' `load`/`store!` and Atomix' `get`/`set!`).
Julia still emits `unordered` loads of heap references that don't involve
an allocation, e.g. of a `DataType` field of an immutable struct, or of a
reference to a mutable object, passed by reference to a `@noinline`
function. Without the demotion, those fail SPIR-V validation with the
Khronos translator, and Metal rejects them once it lowers LLVM atomics
(they are pointer-sized, and outside device and threadgroup memory).
Demote only these, leaving the user atomics with other orderings alone.
@maleadt
maleadt force-pushed the tb/remove-atomics-demotion branch from 971e6ae to 18fe349 Compare September 29, 2026 12:36
@maleadt maleadt changed the title Remove the demotion of atomic loads and stores Only demote unordered atomic loads and stores Sep 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant