This is an archive of the discontinued LLVM Phabricator instance.

[2/2][LiveDebugVariables] Avoid reduntant DBG_VALUEs after virtregrewrite
AbandonedPublic

Authored by djtodoro on Jun 28 2021, 6:54 AM.

Details

Summary

This is a follow-up for the D105025. It tries to find duplicates even further.

Diff Detail

Event Timeline

djtodoro created this revision.Jun 28 2021, 6:54 AM
djtodoro requested review of this revision.Jun 28 2021, 6:54 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 28 2021, 6:54 AM

Hi @djtodoro,

Thanks for splitting the review into two. If D105025 gets accepted as it is then this one makes sense and LGTM. The patch summary could probably be a little more descriptive though. Maybe something like "Ignore instructions that do not modify the variable location when searching backwards for duplicate DBG_VALUEs, rather than stopping the search"?

Lastly, I think it might be worth having a dedicated test for this - or if not, at least adding a comment into the modified test so that it's clear that this feature is being tested. I'm worried that the test could change or go away without us noticing and we'd lose the testing coverage. wdyt?

llvm/lib/CodeGen/LiveDebugVariables.cpp
1640

Please can you update the comment since this function does now look through some non-debug instrs?

1661–1662

nit: It might be nice if there was a way to arrange this loop that avoids the it = std:next(it) requirement on every continue - I can't think of an easy way to do it though.

I just wanted to add, this change makes the quadratic case mentioned by @jmorse in D105025 more likely since the function is able to scan back further in some cases. If your performance testing shows that these patches noticeably impact compile time - as an alternative to the "already inserted DBG_VALIE cache map" solution with this patch in mind - it might be worth trying the approach of RemoveRedundantDbgInstrs (added in D71478)? i.e. Let LiveDebugVariables insert all the DBG_VALUES it usually does and then run a cleanup afterwards that only needs to traverse the instructions twice.

@Orlando Thanks for your comments! Hmm, yes.. I've seen this patch, and I think it is a good approach, but I wanted to avoid introducing a new LLVM pass -- but as you pointed out, why not, it should be acceptable with the respect to time.

djtodoro abandoned this revision.Jul 1 2021, 6:52 AM

Alternative implemented as D105279.