Repository navigation
write barriers: declare that they read their argument memory - #63463
Merged
Merged
Conversation
vchuravy
added this pull request to stack #63466
September 28, 2026 17:00
This was referenced Sep 28, 2026
vchuravy
added
compiler:codegen
vchuravy
marked this pull request as ready for review
October 3, 2026 02:19
vchuravy
force-pushed
the
vc/effects-2-barrier-argmem
branch
from
October 3, 2026 02:21
1d2eeef to
9ba1e08
Compare
The barrier inspects the parent's and children's headers, and it must stay ordered after the store it guards. Declaring argmem reads pins a store above its own barrier, so once calls may carry narrowed memory effects a store can no longer be sunk past a later safepoint that unqueues the parent object. JuliaLICM's barrier hoisting is unaffected: it relies on the stored value staying live across in-loop safepoints and survivors being promoted to old, not on the store/barrier adjacency. Assisted-by: Claude Code (Fable 5.1)
vchuravy
force-pushed
the
vc/effects-2-barrier-argmem
branch
from
October 5, 2026 05:40
9ba1e08 to
d721f58
Compare
xal-0
pushed a commit
that referenced
this pull request
Oct 6, 2026
write barriers: declare that they read their argument memory
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Second of a 4-PR stack re-landing #61394: #63462 → #63463 → #63464 → #63465.
getWriteBarrierAttributescurrently declares the barrier intrinsicsmemory(inaccessiblemem: readwrite). This addsargmem: read: the barrier does inspect the parent's and children's headers, and, more importantly, reading the slot's memory pins the guarded store above its own barrier. Once calls may carry narrowed memory effects (#63464), that is what prevents LLVM from sinking a store past a later safepoint that has meanwhile unqueued the parent object from the remembered set — one of the concerns raised in the #62697 discussion.Today every Julia call is
memory(readwrite)and pins stores by itself, so this has no effect on master's optimization output beyond forbidding a reordering that was never desirable.Note for reviewers:
JuliaLICMalready hoists loop-invariant write barriers out of loops (leaving the store inside, with safepoints in between). That is sound because the stored value stays rooted across the in-loop safepoints and survivors are promoted to old (gc-stock.c,bits = GC_OLD; // promote), so the real invariant is "the stored value is live across the safepoint", not store/barrier adjacency. This PR does not change that.🤖 Generated with Claude Code