@uweigand Thanks for the note and comment!
Fri, Jul 12
@dstenb Thanks a lot, that seems useful!
-Make a wrapper around the getCallPreservedMask() and use it in order to avoid changes in generated code
Thu, Jul 11
@dstenb Thanks a lot!
LGTM! Thanks @vsk!
Tue, Jul 9
Mon, Jul 8
Yes, that sounds good to me!
-Remove redundant code
-Fix the debug entry value assertion from the VarLoc constructor
-Nit in a comment
Fri, Jul 5
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.
Thu, Jul 4
-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..
Wed, Jul 3
Is this OK to go ?
Tue, Jul 2
-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!
Mon, Jul 1
-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
Thu, Jun 27
Wed, Jun 26
Thu, Jun 20
@aprantl The comment looks OK? :)
@aprantl This still looks OK after the rebasing? :)
Jun 20 2019
-Add the comment explaining the assertion when deleting instructions
Jun 17 2019
Jun 10 2019
-Remove an unwanted code refactor change
Jun 6 2019
-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
Jun 5 2019
@dstenb Thanks for the comment!
Jun 4 2019
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!
May 31 2019
(2) function declarations may have a unique DISubprogram attached (new)
In addition, this will address only this.
-Remove the SP flag
-Attach a unique sp to a declaration for the purpose of call site dbg info
May 30 2019
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?
-Refactor the code
-Change the test case