In D58042#1530823, @djtodoro wrote:

@dstenb Thanks for the comment!

Yes, we are constantly measuring debug location statistics. It is possible (and it makes sense) to extend the existing location statistic reporting, within LLVM, by avoiding locations that are entry values (we are actually working on that).

We will share the numbers.

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?

In D61600#1527114, @NikolaPrica wrote:

Have you tested the performance when compiling Clang with ASAN enabled to make sure we're not accidentally regressing because of the more thorough single-location check?

I've built LLVM with '-DLLVM_USE_SANITIZER=Address' using downloaded clang binary to produce private clang binary. I've run tests and compiled latest version of gdb with new private binary and I didn't see any regression there. Is that what you meant?

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).

In D61600#1518157, @NikolaPrica wrote:

Do you think that this is ready for landing now?

Address comments (add MachineInstr:isUndefDebugValue query function)

In D61600#1518010, @dstenb wrote:

Nit: Perhaps we should move the Value class out of DebugLocEntry now that we use it for DbgVariable also? However, I don't have any good ideas on in where to place it (e.g. which header file). I think we can land this without doing such a refactoring though.

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.

Update test cases after review comments.

Adding a comment about another hand-written example.

(Adding Jeremy as reviewer as he has also been working in this area recently.)

In D58042#1484188, @dstenb wrote:

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.

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.

(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.)

Hi! One of the tests was missing "REQUIRES: asserts", so it failed on a non-assert build. I took the liberty to add that to the test in r358057. I hope that was okay!

Slight adjustment: Add an isEnded() query function rather than using getEnd(). An isEnded() function is added in the follow-up patch D59941, so we can avoid unnecessary diffs in that patch by adding such a function here also.

Address review comments.

Rebase, and add Doxygen comment.

In D59942#1456415, @aprantl wrote:

If there are remaining patches that I haven't accepted yet, please ping them.

Ping.

Ping.

Thanks for the review! Just so that I don't misunderstand something; is the LGTM specifically for the changes in this patch, or does that imply the entire patch series?

Address review comments.

Rebase after update of D59941.

Doxygenize comments.

Address comments.

In D59942#1447919, @aprantl wrote:

Is there any performance hit?

In D59941#1447940, @aprantl wrote:

What's the performance impact of this change? Specifically, I'd be interested in the wall clock time difference for building an RelWithDebInfo+asan build of clang.

This patch depends on four preceding refactoring commits. I avoided adding reviewers to two of them (I should perhaps have done the same for the other two) to avoid spamming all of you (who probably deals with enough revisions as it is), but they are up for review.

I have not read through everything yet, but thanks for documenting this!