[Exclusivity] Support exclusivity checks originating from block arguments #20522
Conversation
shajrawi
force-pushed
the
block_args
branch
3 times, most recently
from
372fa72 to
964649f
Compare
|
@swift-ci Please smoke test |
|
Seems like the linux bots are red with an unrelated problem in Clang importer |
|
And the Mac bots are red in LLVM... |
| @@ -536,8 +536,6 @@ void AccessConflictAndMergeAnalysis::identifyBeginAccesses() { | |||
| // here as an invalid `storage` value. | |||
| const AccessedStorage &storage = | |||
| findAccessedStorageNonNested(beginAccess->getSource()); | |||
| if (!storage) | |||
There was a problem hiding this comment.
The comment above explains that this optimization should bail out on unrecognized patterns, which may be generated by various SILOptimizer passes between the time that we select enforcement for markers and the time that we optimize them. This should still bailout and none of the other code in this pass should assume that access markers have a valid storage object.
There was a problem hiding this comment.
As long as we make it clear that the mapped storage may be invalid and comment getAccessInfo then it seems like this could work.
There was a problem hiding this comment.
I added a long comment explaining this
…ents This includes: 1) Not crashing in AccessEnforcementOpts in case we have an Unidentified storage access - rdar://problem/45956642 and rdar://problem/45956777 2) Actually supporting finding the storage locations if we do begin_access <block argument> 3) Test case for said support
|
@swift-ci Please smoke test |
This includes:
<block argument>