This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo] Update MachineInstr interface to better support variadic DBG_VALUE instructions
ClosedPublic

Authored by StephenTozer on Jun 15 2020, 9:40 AM.

Details

Summary

Following on from this RFC[0] from a while back, this is the first patch towards implementing variadic debug values. The current goal is to add a separate parallel instruction, @llvm.dbg.value.var in IR and DBG_VALUE_VAR in MIR; the reason for doing this is that although this is in many ways a small functional change it will change the operands of the instruction, and the code changes necessary to support it are significant. It may be suitable as a total replacement for the old instruction when finished but there may be justifications for keeping them separate, such as the removal of the offset field or the increased complexity and verbosity of the new instruction. The current design of the instruction is mostly as discussed in the RFC, with no implicit pushing of arguments to the stack, and the exact description will be in the following patch (which adds the instruction).

This patch specifically adds a set of functions to MachineInstr for performing operations specific to debug values, and replacing uses of the more general functions where appropriate. The most prevalent of these is replacing getOperand(0) with getDebugOperand(0) for debug-value-specific code, as the operands corresponding to values will no longer be at index 0, but index 2 and upwards: getDebugOperand(x) == getOperand(x+2). Similar replacements have been added for the other operands, along with some helper functions to replace oft-repeated code and operate on a variable number of value operands.

This patch should be NFC but I'm in the process of hunting down some issues that have appeared since rebasing my work onto current master; I don't expect any significant changes to result from this.

[0] http://lists.llvm.org/pipermail/llvm-dev/2020-February/139376.html

Diff Detail

Event Timeline

StephenTozer created this revision.Jun 15 2020, 9:40 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 15 2020, 9:40 AM

Hi @StephenTozer, thanks for this!
I guess we should wait for the rest of the patches, so we have the whole picture and motivation for this.

Fixes broken tests and code error.

vsk added a subscriber: vsk.Jun 17 2020, 3:32 PM

I think this is a really nice step towards hiding some of the implementation details of debug instructions. I especially appreciate that code that operates on debug instructions becomes clearer.

llvm/include/llvm/CodeGen/MachineInstr.h
467

Is it possible to take this further and assert that getOperand() is not called on a debug instruction?

llvm/test/CodeGen/MIR/Generic/dbg-value-missing-loc.mir
41 ↗(On Diff #271348)

What necessitates this change?

StephenTozer marked 2 inline comments as done.Jun 18 2020, 3:39 AM
StephenTozer added inline comments.
llvm/include/llvm/CodeGen/MachineInstr.h
467

getOperand() is still used (internally) by the debug-specific getters, although it could be replaced by Operands[i]. I'm not sure if reducing the interface so drastically would be ideal though; code that is agnostic about the type of instruction it operates on - such as replacing register usage - would break for debug values, and have to be rewritten to accomodate. That wouldn't necessarily be a bad thing though, since we might actually want different code in all those places.

llvm/test/CodeGen/MIR/Generic/dbg-value-missing-loc.mir
41 ↗(On Diff #271348)

Some of the previous code dealing specifically with debug values had some statements along the lines of if (MI.isDebugValue() && MI.getOperand(2).isMetadata()) {...}. As of this patch we're now using specific functions, i.e. getDebugVariable(), that assert that the operand is the right type and then cast to it. AFAIUI this shouldn't be a breaking change as we never produce DBG_VALUEs without the "right" operands, like this test had.

vsk added inline comments.Jun 18 2020, 12:38 PM
llvm/include/llvm/CodeGen/MachineInstr.h
467

Ah that's right, there is a fair amount of code that transparently updates debug instructions. I ran into this some time ago while trying to make the MachinerRegisterInfo use/def iterators skip debug instructions by default. It can be hard to tell whether a piece of code is intentionally updating debug instructions.

llvm/test/CodeGen/MIR/Generic/dbg-value-missing-loc.mir
41 ↗(On Diff #271348)

I see that specific check in LiveDebugVariables, but I'm not sure why it would apply here since we're just running the verifier.

It's fairly common for backend authors to write tests with incomplete/malformed DBG_VALUEs as it's vastly more convenient than wiring up actual debug info metadata (see e.g. X86/branchfolding-debug-invariant.mir). It'd be great if we could keep that feature.

StephenTozer marked an inline comment as done.Jun 19 2020, 9:54 AM
StephenTozer added inline comments.
llvm/test/CodeGen/MIR/Generic/dbg-value-missing-loc.mir
41 ↗(On Diff #271348)

The tolerance here might be dependent on exactly which passes we go through; in some cases it might not be reasonable to assume malformed DBG_VALUEs. This test breakage specifically came from MachineInstr::print however, so it shouldn't be a problem to fix this case (all other tests pass currently).

I think this is a really nice step towards hiding some of the implementation details of debug instructions. I especially appreciate that code that operates on debug instructions becomes clearer.

Agreed. Thanks!

Allow for malformed DBG_VALUEs to be printed.

vsk accepted this revision.Jun 19 2020, 12:31 PM

Thank you!

This revision is now accepted and ready to land.Jun 19 2020, 12:31 PM
This revision was automatically updated to reflect the committed changes.