[rebranch] Cherry-pick debug info entry value fixes #7311
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 class 'DbgVariable' can be in one of three states, and the "is any of them initialization" logic for them is repeated in a couple of places. We may want to expand this class in the future; as such, we factor out this common logic so that it is easier to modify. Differential Revision: https://reviews.llvm.org/D158438 (cherry picked from commit 3222312)
…g.declare When we convert an EntryValue dbg.declare into an entry of the MF side table, we currently copy its DIExpression as is, and rely on subsequent layers to "know" that this expression is implicitly indirect. This is bad because it adds an implicit assumption to the IR representation, and requires subsequent layers to know about this assumption. This also limits the reusability of this table: what if, in the future, we want to use this table for dbg.values? This patch changes existing behavior so that the entities converting dbg_declares explicitly add an OP_deref when converting EntryValue dbg.declares. Differential Revision: https://reviews.llvm.org/D158437 (cherry picked from commit 8841709)
With D149881, we converted EntryValue MachineFunction table entries into `DbgVariables` initialized by a "DbgValue" intrinsic, which can only handle a single, non-fragment DIExpression. However, it is desirable to handle variables with multiple fragments and DIExpressions. To do this, we expand the `DbgVariable` class to handle the EntryValue case. This class can already operate under three different "modes" (stack slot, unchanging location described by a dbg value, changing location described by a loc list). A fourth case is added as a separate class entirely, but a subsequent patch should redesign `DbgVariable` with four subclasses in order to make the code more readable. This patch also exposed a bug in the `beginEntryValueExpression` function, which was not initializing the `LocationFlags` properly. Note how the `finalizeEntryValue` function resets that flag. We fix this bug here, as testing this changing in isolation would be tricky. Differential Revision: https://reviews.llvm.org/D158458 (cherry picked from commit af6d43e)
We should also test the x86 target, since it has different backend defaults from ARM. Differential Revision: https://reviews.llvm.org/D158636 (cherry picked from commit 27425ae)
… targets Only X86_64 and ARM64 have a reserved register for async arguments, and so the debugger is only able to handle those targets. For other architectures, we use a non-entry-value expression and let the debugger do its best with that. Differential Revision: https://reviews.llvm.org/D158638 (cherry picked from commit aefa9ff)
This dependency was introduced by D158638. It seems harmless to add this, as the Analysis library also does it. Differential Revision: https://reviews.llvm.org/D158729 (cherry picked from commit fdb734a)
When SelectiondDAG converts dbg.value intrinsics, it first ensures we have already generated code for the value operator of the intrinsic. The rationale being that if we haven't had the need to generate code for this value, it won't be a debug value that causes the generation. For example, if the first use the physical register of an argument is a dbg.value, we are going to hit this code path. However, this is irrelevant for entry value expressions: by definition we are not interested in the _current_ value of the physical register, but rather on its value at the start of the function. To deal with this, this patch changes lowering to handle this case as early as possible. Differential Revision: https://reviews.llvm.org/D158649 (cherry picked from commit 35f4ef1)
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.
This is a collection of patches from upstream submitted to address debug info failures.
We still need https://reviews.llvm.org/D158185 and one more SelectionDAG patch that is still being worked on.