@uweigand Thanks for the note and comment!

@dstenb Thanks a lot, that seems useful!

-Make a wrapper around the getCallPreservedMask() and use it in order to avoid changes in generated code

@uweigand Thanks for that! The commit is reverted with the rL365886.

@dstenb Thanks a lot!

LGTM! Thanks @vsk!

Yes, that sounds good to me!

@dstenb Thanks!

-Remove redundant code
-Fix the debug entry value assertion from the VarLoc constructor

-Nit in a comment

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

Just to clarify, as the emission of entry values is behind a non-driver flag I'm not opposed to landing these patches without changing llvm-dwarfdump, so please don't let me stand in the way. I think that a "non-entry-val scope bytes covered" field would be helpful, but someone with more say in the debug info area than me should decide that.

-Fixing unintentional code during the rebase process

-Fix the assertion

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

Is this OK to go ?

-Add support for entry values that are complex variables address (that avoids entry value not be safe for a single locations)
-Add a TODO for supporting local variables that are expressed in terms of parameters entry values

Would it perhaps make sense to add a small sentence about that in those TODOs?

@dstenb Sure! Thanks!

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!

-Clarify in the test the entry value coming from a location list

Due to very latest patches we came up with situations when we need to avoid single location represented as an entry value.
Also, having in mind the debug entry value is special case of the 'DBG_VALUE' instruction, we found it is OK in some situations to generate it after a first terminator.
Is this still OK to go ?

Nit: Use DWARF 5 in a test case.

-Avoid a single location represented as an entry value (+ add a test for that)
-Allow a debug entry value after a first terminator

@aprantl The comment looks OK? :)

@aprantl This still looks OK after the rebasing? :)

-Rebase

-Rebase

-Rebase

-Rebase
-Add the comment explaining the assertion when deleting instructions

-Remove an unwanted code refactor change

-Handle a deletion in the LiveRangeEdit

-Handle the TargetDecl in more secure way (the same as the other code in the function)

-Explicitly enable the option only in the case of X86

@dstenb Thanks for the comment!

Oh.. and could you please document this either in LangRef.rst or SourceLevelDebugging.rst?

Sure. Please find it in the latest patch.
Thanks for your comments!

-Address suggestions
-Document this

(2) function declarations may have a unique DISubprogram attached (new)

In addition, this will address only this.

@aprantl , @dexonsmith Thanks for your comments!

-Rebase tests

-Rebase tests

-Rebase

-Remove the SP flag
-Attach a unique sp to a declaration for the purpose of call site dbg info

I'm sorry if the answer to that question is already in your reply and I just failed to parse it: Why do we need the DISPFlagDeclForCallSite *flag* to differentiate the a DISubprogram. Isn't the fact that it is attached to a forward-declaration enough?

-Rebase

-Refactor the code
-Change the test case