Only inject thread barriers where threads disagree about memory - #9390
Open
abadams wants to merge 2 commits into
Open
Only inject thread barriers where threads disagree about memory#9390abadams wants to merge 2 commits into
abadams wants to merge 2 commits into
Conversation
InjectThreadBarriers visited Blocks pairwise, so it put a barrier at every join in a sequence of statements regardless of whether the two halves touched any of the same memory. Take the whole sequence at once and compare each statement's footprint against everything since the last barrier, emitting one only for a genuine read-after-write, write-after-read, or write-after-write. A barrier only fences the memory spaces named in its mask, so it only clears the footprint of those spaces. Accesses in a space it did not fence are still waiting for a barrier of their own. The footprint is keyed on the storage a Func ends up in rather than its name. ExtractSharedAndHeapAllocations pools allocations with disjoint lifetimes onto the same memory, so two differently named Funcs can be the same bytes at different times, and the hazard between them is real. allocate_funcs takes its argument by value, because the grouping is now asked for twice and sorting the caller's vector would make the second answer depend on the first. Textures are counted too. They are reached through image_load and image_store rather than Load and Store, so walking for the latter alone would miss a Func stored in MemoryType::GPUTexture entirely. Across the correctness tests this drops the number of barriers emitted from 259 to 181. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## abadams/block_to_vector #9390 +/- ##
===========================================================
- Coverage 70.11% 70.05% -0.07%
===========================================================
Files 261 261
Lines 79190 79355 +165
Branches 19305 19336 +31
===========================================================
+ Hits 55524 55591 +67
- Misses 17893 17920 +27
- Partials 5773 5844 +71 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
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.
InjectThreadBarriers visited Blocks pairwise, so it put a barrier at every join in a sequence of statements regardless of whether the two halves touched any of the same memory. Take the whole sequence at once and compare each statement's footprint against everything since the last barrier, emitting one only for a genuine read-after-write, write-after-read, or write-after-write.
A barrier only fences the memory spaces named in its mask, so it only clears the footprint of those spaces. Accesses in a space it did not fence are still waiting for a barrier of their own.
The footprint is keyed on the storage a Func ends up in rather than its name. ExtractSharedAndHeapAllocations pools allocations with disjoint lifetimes onto the same memory, so two differently named Funcs can be the same bytes at different times, and the hazard between them is real. allocate_funcs takes its argument by value, because the grouping is now asked for twice and sorting the caller's vector would make the second answer depend on the first.
Textures are counted too. They are reached through image_load and image_store rather than Load and Store, so walking for the latter alone would miss a Func stored in MemoryType::GPUTexture entirely.
Across the correctness tests this drops the number of barriers emitted from 259 to 181.