This is an archive of the discontinued LLVM Phabricator instance.

Improvements to call site register worklist
ClosedPublic

Authored by dstenb on Jan 22 2020, 2:57 AM.

Details

Summary

This fixes PR44118. For cases where we have a chain like this:

R8 = R1 (entry value)
R0 = R8
call @foo R0

the code that emits call site entries using entry values would not
follow that chain, instead emitting a call site entry with R8 as
location rather than R0. Such a case was discovered when originally
adding dbgcall-site-orr-moves.mir. This patch fixes that issue. This is
done by changing the ForwardedRegWorklist set to a map in which the
worklist registers always map to the parameter registers that they
describe.

Another thing this patch fixes is that worklist registers now can
describe more than one parameter register at a time. Such a case
occurred in dbgcall-site-interpretation.mir, resulting in a call site
entry not being emitted for one of the parameters.

Diff Detail

Event Timeline

dstenb created this revision.Jan 22 2020, 2:57 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 22 2020, 2:57 AM

Nice! Thanks!

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
638

Can we describe the usage of it with a comment?

665

The register worklist ?

669

auto Reg

693

Good NFC, thanks.

llvm/test/DebugInfo/MIR/X86/dbgcall-site-reg-shuffle.mir
50

I believe you don't need all the attributes.

Sorry, I now realized that the RegsToKeep handling is not sufficient, since it will not correctly handle cases where we have a mix of parameter registers that should be discarded, and those that were added in this iteration, which we should keep.

This patch will for example not correctly handle the following example on a made-up architecture:

$r1 = mv-imm 123
$r0, $r1 = mv_registers $r1, <register that can't be described>
call @foo, $r0, $r1

For such code, this patch will produce call site entries for both $r0 and $r1 described by 123, but we should only emit a call site entry for $r0.

That is quite a silly code example, but it seems good to get such a thing right from the start. I'll upload an updated patch.

dstenb updated this revision to Diff 239899.Jan 23 2020, 7:20 AM

Fix the RegsToKeep flaw I mentioned in a previous comment. I added a new test, dbgcall-site-partial-describe.mir, as a reproducer for that.

Address comments.

dstenb marked 4 inline comments as done.Jan 23 2020, 7:28 AM
dstenb added inline comments.
llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
665

"The worklist register" is perhaps a bit poorly phrased, or awkward to read. I meant "The register in the worklist". Perhaps it should just say "ParamFwdReg"?

vsk added a comment.Jan 23 2020, 1:41 PM

This is looking really nice. Thanks!

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
574

I think this needs to be a MapVector. Otherwise, the iteration order in getForwardingRegsDefinedByMI will be non-deterministic. I.e. the insertion order into the Defs SmallSetVector will not be deterministic.

623

Consider adding assert(find(I.first->second, ParamReg) == nullptr && "Same parameter described twice by forwarding reg") before pushing ParamReg?

llvm/test/DebugInfo/MIR/X86/dbgcall-site-partial-describe.mir
76 ↗(On Diff #239899)

I think the first CHECK-NOT for DW_TAG_GNU_call_site_parameter can safely be deleted. Or you could pass -implicit-check-not=DW_TAG_GNU_call_site_parameter to FileCheck and get rid of both CHECK-NOT's.

llvm/test/DebugInfo/MIR/X86/dbgcall-site-reg-shuffle.mir
91

Nice!

djtodoro added inline comments.Jan 23 2020, 11:53 PM
llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
597

Cool :)

dstenb updated this revision to Diff 240186.Jan 24 2020, 7:13 AM
dstenb marked 8 inline comments as done.

Address review comments. Reword a test description slightly.

dstenb added inline comments.Jan 24 2020, 7:22 AM
llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
574

Good catch! As I've understood it the iteration order for a non-pointer type holding DenseMap is deterministic for a single binary? However, I guess it's not free from implementation-defined behavior (e.g. the hash function is dependent on the width of unsigned), so I guess there's no guarantee that the iteration order is deterministic between binaries built with different compilers. I made it a MapVector.

llvm/test/DebugInfo/MIR/X86/dbgcall-site-partial-describe.mir
76 ↗(On Diff #239899)

Oh, right!

I switched to implicit-check-not in both tests.

dstenb marked an inline comment as done.Jan 24 2020, 7:27 AM
dstenb added inline comments.
llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
574

By the way, the DWARF5 standard appears to mandate that the call site parameter entries occur in the same order as they do in the source, which is currently not the case for LLVM. I created a Bugzilla ticket for that: https://bugs.llvm.org/show_bug.cgi?id=44653.

vsk accepted this revision.Jan 24 2020, 10:39 AM

Lgtm!

This revision is now accepted and ready to land.Jan 24 2020, 10:39 AM
This revision was automatically updated to reflect the committed changes.