Looks good. Just a small nit about the test.

Hi, @arichardson! What is the status for this patch?

In D90020#2477208, @sdesmalen wrote:

In D90020#2455122, @dstenb wrote:

I'm sorry for chiming in so late here! I have a comment about the prependOffsetExpression target hook.

Thanks for the suggestion, you made a good point that this interface was error prone when new flags are added in the future. I've updated the patch and added the virtual interface getOffsetOpcodes alongside prependOffsetExpression (made non-virtual and now handles the Deref, Stack/Entry Value). Let me know if this is how you imagined it.

I'm sorry for chiming in so late here! I have a comment about the prependOffsetExpression target hook.

In D76146#2438388, @mib wrote:

Hi @dstenb, any update on this ? I tried to look for DW_OP_LLVM_convert_generic in the codebase but couldn't find any occurence ... Thanks.

Thanks!

As both the emission of the IMPLICIT_DEF instructions in SelectionDAG, and the resolving of those instructions in "Process Implicit Definitions", is target independent code, I think it would be sufficient with only keeping one of these test cases, but I would be fine with landed this with all five.

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.

What is the status of the expensive check failure? It has been present for five days now. Should we revert this patch until that is resolved?

In D91153#2415351, @mkazantsev wrote:

Please move the test out of MIPS-specific into general test directory if it's possible. Otherwise, LGTM.

Use X86 reproducer instead.

I took the liberty to add some review comments whilst familiarizing myself with the code.

In D91153#2393018, @TaWeiTu wrote:

In D91153#2385479, @dstenb wrote:

I'm not very familiar with the IndVars pass, so I have not idea if this is the correct way to solve this.

This seems correct to me, but I'm not familiar with IndVar either, so maybe someone else should take a look.
However, I think it would be better if we can return false in this case (i.e. if all PHI nodes created in rewriteLoopExitValues are dead).
But I don't know whether there's some edge case that forces us to return true here.

Thanks! This looks good to me.

I'm not very familiar with the IndVars pass, so I have not idea if this is the correct way to solve this.

In D89613#2376068, @vtjnash wrote:

The .cfi_startproc directive is part of the unwind information (eh_frame), and is not debug info, so that seems like a possible bugfix even? I'd expect that observation to be consistent with the goal of this PR, though I didn't see specifically where that pass was being affected in a cursory glance back through the PR.

In D53758#2336719, @dexonsmith wrote:

I totally lost track of this :/.

The patch looks correct, thanks very much for tracking this down. This LGTM if you add an explanation to the testcase of exactly what it’s testing (I worry it’s not obvious for someone trying to update the test later).

Rebase, and update comment in test case.

This seems to have broken the expensive-checks build bots:

If I understand this correctly, the new {EntryValue, EntryExpr} operands do, if EntryExpr is not undef, specify a location that is identical to the dbg.value's current {Value, Expr} operands, but with DW_OP_LLVM_entry_value implicitly being applied to EntryValue before EntryExpr. Is that correct?

Some minor code style comments while I look into this.

I added a comment about eliminateTrunc to the commit message. I'll see if I can create a reproducer for that, and if so, I'll upload a revision for that.

I'm equally fine with doing the Implicit flag change here, or for someone to do it in a separate patch.

Sorry for a piecemeal review from my part!

Thanks for the review!

Just some drive-by nits while familiarizing myself with this patch series.

Continue using a bool return instead of a tri-state.

Thanks, and sorry for overlooking the comments!

I will go through this more deeply, but just an initial comment is that I think it may be worth considering splitting it into two patches, in order to make it easier to review:

Address review comments.

LGTM!

Thanks for the review!

Ping.

Gentle ping. I was not sure which reviews to add to this one, since the code has mostly remained unchanged since its original introduction in 2004, except for it being affected by wider changes.

I'll land this with a comment added to the test case in the meanwhile.

In D86085#2221693, @asbirlea wrote:

If you'd be able to add reproducers in follow up patch, that would be great.

Slight refactoring of the existing test case, and add test cases for the other two returns.