-
Notifications
You must be signed in to change notification settings - Fork 4.8k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Value numbering supports precise numbering of field accesses using "maps": where each access is modeled as a selection: "map[indices...]". It has been the case until this change that said indices were always "precise" - VNs of field handles. This system has proven to be problematic for representing struct field access: 1) The precise model effectively means that each field access represented by a unique handle cannot alias access to the same location, but using a different handle. This meant that reinterpretation of structs, reasonably common both in user code and in the IR compiler creates itself, was UB. 2) The precise model for struct fields entailed supporting "zero-offset field sequences", which were maintained in a side map and caused a good number of bugs. This change solves both of these problems by eliminating the need to use precise selectors for struct fields, introducing a new kind of selector (and maps to go with it): "the physical selector": offset plus load/store size, with "VNForMapSelectWork" enhanced to look through physical store maps, correctly detecting aliasing. The precise selection rules are maintained for the maps indexing off of the heap, where we don't have the same aliasing concerns. Physical maps are now used exclusively for numbering locals. This change seeks to preserve previous behavior to avoid diffs: many places with now-not-needed pessimization are marked with "TODO-PhysicalVN". Similarly, the field sequence infrastructure supporting the old precise selection scheme is retained in its full generality. Future changes are expected to remove much of it.
- Loading branch information
1 parent
e03614d
commit ed2472b
Showing
12 changed files
with
1,441 additions
and
1,218 deletions.
There are no files selected for viewing
This file contains 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
This file contains 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
Oops, something went wrong.