[Exclusivity] Relax enforcement for separate struct stored properties #10235
Conversation
Relax the static enforcement of exclusive access so that we no longer diagnose on accesses to separate stored structs of the same property: takesInout(&s.f1, &s.f2) // no-warning And perform the analogous relaxation for tuple elements. To do this, track for each begin_access the projection path from that access and record the read and write-like modifications on a per-subpath basis. We still warn if the there are conflicting accesses on subpaths where one is the prefix of another. This commit leaves the diagnostic text in a not-so-good shape since we refer to the DescriptiveDeclKind of the access even describing a subpath. I'll fix that up in a later commit that changes only diagnostic text. https://bugs.swift.org/browse/SR-5119 rdar://problem/31909639
|
@swift-ci Please smoke test and merge |
|
|
||
| func inoutSameTupleElement() { | ||
| var t = (1, 4) | ||
| takesTwoInouts(&t.0, &t.0) // no-error |
There was a problem hiding this comment.
This still says "no error".
There was a problem hiding this comment.
Thanks! The no-errors are fixed in #10273.
|
|
||
| func inoutSameTupleNamedElement() { | ||
| var t = (name1: 1, name2: 4) | ||
| takesTwoInouts(&t.name2, &t.name2) // no-error |
There was a problem hiding this comment.
This still says "no error".
|
|
||
| func inoutSamePropertyInSameTuple() { | ||
| var t = (name1: 1, name2: StructWithTwoStoredProp()) | ||
| takesTwoInouts(&t.name2.f1, &t.name2.f1) // no-error |
There was a problem hiding this comment.
This still says "no error".
| class RecordedAccess { | ||
| private: | ||
| BeginAccessInst *Inst; | ||
| ProjectionPath SubPath; |
There was a problem hiding this comment.
We discussed this in person but in the interest of public information,
it is unfortunate that we have a fully general looking utility called
"ProjectionPath" that is usually not what a pass should use to
represent projection paths. When representing access paths across a
multitude of accesses, a prefix trie should be used with each path
represented by a single pointer that identifies a unique integer
sequence along with any pass-specific data.
This approach should be both simpler and much more scalable. The
Load/Store optimizer regrettably made the mistake of using
ProjectionPath. It is quite expensive and not scalable.
We definitely should not build ProjectionPaths at -Onone.
There was a problem hiding this comment.
I'm working on a fix to use the index trie from DeadObjectElimination you mentioned.
Relax the static enforcement of exclusive access so that we no longer diagnose
on accesses to separate stored structs of the same property:
takesInout(&s.f1, &s.f2) // no-warning
And perform the analogous relaxation for tuple elements.
To do this, track for each begin_access the projection path from that
access and record the read and write-like modifications on a per-subpath
basis.
We still warn if the there are conflicting accesses on subpaths where one is
the prefix of another.
This commit leaves the diagnostic text in a not-so-good shape since we refer
to the DescriptiveDeclKind of the access even describing a subpath.
I'll fix that up in a later commit that changes only diagnostic text.
https://bugs.swift.org/browse/SR-5119
rdar://problem/31909639
Resolves SR-5119.