Hi, thanks for your comments!

@djtodoro Thanks for the review!

• Rebase on top of the D115616
• Remove extra new line

• Rebase
• Don't use legacy Pass Manager in tests

Thank you for the comments, @aeubanks.
My replies are inline.

Rebase.

• Add new argument usage to HowToUpdateDebugInfo documentation

Thanks @djtodoro!

Set limitation granularity to the function level instead of instruction level.

• After latest update of D115622, we decide whether to use already collected Debug Info at the Function level, instead of the (whole) Module level. This is important, since the set of observed Functions in the same Module is not the equivalent for each pass in the LLVM pipeline. This update of the patch introduces the limit number of the observed Functions in the -verify-each-debuginfo-preserve pipeline.
• By default, consider unlimited number of Functions
• Set any number as a limit using the -debugify-func-limit option
• Rebase

Hi @StephenTozer, sorry for the delay, I was AFK.
Thanks for your comments.

Addressed comments.
@StephenTozer Thanks for the comments, I agree with all the suggestions.

Reformat the code.
@jmorse, @djtodoro Any additional comments? Thanks.

@djtodoro Thanks for the comments, I agree with all of them.

• Address comments from @djtodoro
• Rebase

• Address comments
• Refactor removeEntryValue
• Add a test for the loop case emphasized by @jmorse

Hi Jeremy,
Thanks for the comments.

In D94685#2504510, @atanasyan wrote:

@ntesic Do you have commit access?

Addressed comments:

• Use shouldUpdateCallSiteInfo() predicate
• Use ToErase->eraseFromParent()
• Reduce function attributes in test

In D78105#2487169, @nickdesaulniers wrote:

Compiler crash reported in: https://bugs.llvm.org/show_bug.cgi?id=48695

@dstenb @djtodoro Sure, I will keep only one test.
Thanks for the review!

• Move implementation to DwarfDebug
• Update tests to check DWARF

In D92471#2428505, @dstenb wrote:

I think it would be preferable if we could do this in a target independent place, so that downstream targets, and upstream targets that do not yet support call sites, do not have to care about this.

Can we do this in collectCallSiteParameters by looking at the call instruction's undef uses?

Something like this:

@@ -787,6 +787,15 @@ static void collectCallSiteParameters(const MachineInstr *CallMI,
     (void)InsertedReg;
   }
 
+  for (auto &MO : CallMI->uses()) {
+    if (!MO.isReg() || !MO.isUndef())
+      continue;
+    auto It = ForwardedRegWorklist.find(MO.getReg());
+    if (It == ForwardedRegWorklist.end())
+      continue;
+    ForwardedRegWorklist.erase(It);
+  }
+

@dstenb Thanks for the review. Any additional comments?

Address comment - delaySlotSupported change.
Compress test-CHECK-lines.

Clang format.

Address comments.
Rebase.

Capture "&" instead of "this" in delaySlotSupported lambda.

Address comments.
Change of delay slot guard - use assertions instead of target check.

Address comments.
Transform lambda

nextInstrInterpret

into static function

interpretNextInstr

Address comment - spelling.
Rebase.

In D78105#2035965, @dstenb wrote:

LGTM. Thanks!

Do you need help with landing this?

Address comments:

• tests changes
• patch summary update

In D78105#2025646, @vsk wrote:

This seems to be in great shape. Does it have any dependencies?

Address comment.
Tests update - use only one !DILocation per scope.

The main purpose of the "delay slot guard" is to ensure that call_site DIE won't be created for call with delay slot, because it could have incorrect "return PC" value (DW_AT_low_pc, DW_AT_call_return_pc).
This will happen if the call and its delay slot instruction are not in the expected order.

Address comment.

Address comments.
@dstenb @djtodoro Thanks for your suggestions.

Address comments.

Merging into https://reviews.llvm.org/D78105.

Address comment.
Add changes from https://reviews.llvm.org/D78104.

Address comments.

@dstenb
Thanks for the review.
I agree with all suggestions.

In D78104#1985262, @aprantl wrote:

This would benefit from some kind of test.