Skip to content

[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
merged 9 commits into from
May 13, 2024

Conversation

Snowy1803
Copy link
Member

@Snowy1803 Snowy1803 commented May 9, 2024

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:

  • DeadObjectElimination using the wrong location and scope (now loses 18% less variables)
  • SILCombine existential opening was using the wrong scope (loses 0.02% less variables)
  • SILCombine emitting wrong debug info for eliminated enums (loses 0.02% less variables)

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.

Snowy1803 added 3 commits May 8, 2024 16:43
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.
@Snowy1803
Copy link
Member Author

@swift-ci please test

@Snowy1803
Copy link
Member Author

@swift-ci please test source compatibility

@Snowy1803 Snowy1803 force-pushed the complete-getvarinfo branch from d88173a to 52ed135 Compare May 10, 2024 21:27
Snowy1803 added 5 commits May 10, 2024 16:09
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.
@Snowy1803 Snowy1803 force-pushed the complete-getvarinfo branch from 52ed135 to 56f320e Compare May 10, 2024 23:13
@Snowy1803
Copy link
Member Author

@swift-ci please test

@Snowy1803 Snowy1803 marked this pull request as ready for review May 10, 2024 23:14
@Snowy1803 Snowy1803 requested a review from kavon as a code owner May 10, 2024 23:14
@Snowy1803 Snowy1803 force-pushed the complete-getvarinfo branch from 56f320e to d49387b Compare May 11, 2024 00:36
@Snowy1803
Copy link
Member Author

@swift-ci please test

@Snowy1803 Snowy1803 force-pushed the complete-getvarinfo branch from d49387b to 9984d1d Compare May 11, 2024 01:47
@Snowy1803
Copy link
Member Author

@swift-ci please test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants