- User Since
- Jun 10 2016, 1:55 AM (171 w, 3 d)
Fri, Sep 20
Thu, Sep 19
Update patch after comments, and change the semantics of the new operation. Rather than only introducing an internal variant that has the same behavior as DW_OP_entry_value, the new operation's operand specifies the number of operations (including the value/address operand) that are covered by the entry value, and that value is then converted to the byte size when we emit the entry value in DwarfExpression.
Thanks for looking at the changes!
Tue, Sep 17
Mon, Sep 16
In general, is it really safe to describe loaded values at the call sites?
Thu, Sep 12
Sun, Sep 8
Thanks for the reviews! I'll land these commits shortly.
Fri, Sep 6
Address the rest of the comments.
Rebase on top of pointer -> object refactoring.
Thu, Sep 5
I have experimented a bit with making the describeLoadedValue() hook return machine operand objects rather than pointers, as that can simplify the code slightly.
Fri, Aug 30
Thu, Aug 29
Add MachineBasicBlock::insertAfterBundle() helper function.
Wed, Aug 28
Tue, Aug 27
Mon, Aug 26
It might be worthwhile to try to reduce the reproducer with Bugpoint.
Aug 19 2019
(A bit related to aprantl's latest comment.)
Aug 15 2019
Thanks for the reviews! I can let this sit in Phabricator for a few more days to see if there are any more comments before landing it.
Aug 14 2019
Update test case according to comments.
Aug 13 2019
Aug 12 2019
Thanks for the reviews, and sorry for taking some time to land this!
Jul 12 2019
I just want to add that I was a bit hesitant about generalizing the removal as I think it can be quite hard to tell when call site information has been removed, so I thought it would be better to have asserts trigger for each individual case, so that we can detect and assess what to do there, rather than dropping the information silently at the risk of false negatives.
Jul 10 2019
Thanks a lot for your work with this patch series! It seems very useful.
Jul 9 2019
Thanks a lot for putting the patch together so fast!
The tests introduced in this commit currently fail when running UBSan, due to invoking getRegInfo() with RegInfo being null:
Jul 8 2019
Jul 5 2019
Jul 4 2019
Jul 2 2019
Jun 13 2019
Jun 7 2019
Jun 5 2019
Have you measured what the effect the emission of entry value locations has on the "scope bytes covered" statistics? I guess that it can increase quite a bit (especially later if we start describing non-parameter variables using parameter entry values)? If so, if the caller(s) do not have call site information, it will still not be able to print the variable. Would it make sense, and would it be possible, to introduce a "scope bytes covered without entry values" statistic, or some other statistic, which helps you assess how large part of the locations that rely on entry values?
Jun 3 2019
May 28 2019
Add a comment to the query function (undef debug values are mentioned in SourceLevelDebugging.rst, but I did not find any central explanations of such debug values in the code base).
May 27 2019
Address comments (add MachineInstr:isUndefDebugValue query function)
Thanks a lot! This "location list -> single location description" detection seems more robust, and should help us moving towards supporting rewrites of single-entry location lists containing fragments also.
May 24 2019
Update test cases after review comments.
May 23 2019
May 22 2019
Adding a comment about another hand-written example.
May 20 2019
May 15 2019
May 7 2019
(Adding Jeremy as reviewer as he has also been working in this area recently.)
May 6 2019
May 2 2019
Apr 30 2019
I cherry-picked the patches on top of r359425, and tried out some examples. Doing that, I encountered a case where entry values are not inserted with this patch.
Apr 29 2019
(A minor comment, which is not related to the code changes themselves, is that this should be a parent revision to D58033, and not vice-versa as it is now.)