(A bit related to aprantl's latest comment.)

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.

Update test case according to comments.

Thanks for the reviews, and sorry for taking some time to land this!

In D60716#1580513, @djtodoro wrote:

@dstenb Thanks a lot!

That seems like a good catch and we should support such scenario.

I think that it will be expensive to return a MachineOperand object.

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.

Thanks a lot for your work with this patch series! It seems very useful.

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:

In D58042#1571079, @djtodoro wrote:

@dstenb We could land this right now, and the patch for the 'llvm-dwarfdump' stats could be a separate patch. Do you agree?

In D58042#1570411, @djtodoro wrote:

Did you consider what should be done with llvm-dwarfdump's "scope bytes covered" statistics?

I think that it sounds reasonable to add an additional field there, something like "non-entry-val scope bytes covered".

In D58042#1566136, @djtodoro wrote:

The 'llvm-dwarfdump' does calculate the debug location statistics, but maybe we could think of reporting it with more information, since the debug location info is such important debug info. Please find a proposal for having a separate tool that will calculate only the debug location statistics on my github (https://github.com/djolertrk/llvm-locstats) and let me know if it can be useful for us. Potentially, we could add more options, functionalities, etc..

In D58042#1566136, @djtodoro wrote:

Can you change this comment from describing what the code does (which is fairly obvious), to why it does it?

@aprantl Sure. Thanks for the comment!

I'm sorry for the late comment, but in the future I guess this could be extended so that entry_values are emitted for locals that are expressed in terms of parameters, as GCC does?

@dstenb Thanks for your attention and comments. Sure, that is the plan. This is initial set of patches that covers just non-modified function parameters. Even the initial patch within the GCC was handling just this situation. The ways for improving this (using benefits of the debug entry values) are extending the support for modified parameters (if its modification could be described as an expression over its entry value), supporting local variables, etc.

As far as I can tell, we don't tag non-parameter variables as NotModified, but can Clang later on be extended to mark them as such?

Yes, it can be extended.

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.