-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[DebugInfo] Return complete variable info from getVarInfo by default #73555
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
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
The scope of a store has to be the variable's scope. The type should be set to the element's type, and only if not already set. The variable's location should be set.
We should not dereference the file position if this SILLocation is not a position. If it's a pointer, we compare the pointers.
@swift-ci please test |
@swift-ci please test source compatibility |
d88173a
to
52ed135
Compare
We do keep the fragment part of the expression as it is important to identify fragments separately. A variable with less fragments should be considered a superset of variables with more fragments, but that would require to change a lot of code.
The type of the new variable should be opened too. If the variable has an expression modifying the type, it cannot be rewritten and is dropped.
getVarInfo() now always returns a variable with a location and scope. To opt out of this change, getVarInfo(false) returns an incomplete variable. This can be used to work around bugs, but should only really be used for printing. The complete var info will also contain the type, except for debug_values, as its type depends on another instruction, which may be inconsistent if called mid-pass. All locations in debug variables are now also stripped of flags, to avoid issues when comparing or hashing debug variables.
52ed135
to
56f320e
Compare
@swift-ci please test |
adrian-prantl
approved these changes
May 10, 2024
56f320e
to
d49387b
Compare
@swift-ci please test |
d49387b
to
9984d1d
Compare
@swift-ci please test |
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.
getVarInfo() now always returns a variable with a location and scope.
To opt out of this change, getVarInfo(false) returns an incomplete variable.
This can be used to work around bugs, but should only really be used for printing.
The complete var info will also contain the type, except for debug_values, as its type depends on another instruction, which may be inconsistent if called mid-pass.
All locations in debug variables are now also stripped of flags, to avoid issues when comparing or hashing debug variables.
Variable types are now also consistently object types, as there are no address types in Swift.
This PR also fixes some issues that this change uncovered:
Overall, with this PR, we are losing 0.13% less variables at the SIL level. At the DWARF level, we have 1.9% more coverage and 2.5% more variables.