[PATCH] D43850: [CodeGen] Avoid handling DBG_VALUE instructions for stepBackwards

[Matt Davis via Phabricator via llvm-commits]

mattd added a comment.

In https://reviews.llvm.org/D43850#1021573, @MatzeB wrote:

> This is surprising: DBG_VALUE should not have any defs so `removeDefs()` should have no effect and all uses should be marked with the debug flag so none of them should pass the `MachineOperand::readsReg()` test in addUses. Could you check whether the debug flag is set correctly? Did you try running your test with -verify-machineinstrs?


Thanks for the reply and helpful response @MatzeB .  I do not get any diagnostic issues when running my test with -verify-machineinstrs.

I think what might be happening is that, during tail merging, some undef operands were switched to being non-undef.  That wording I ripped from the comment in lib/CodeGen/BranchFolding.cpp: replaceTailWithBranchTo.  This the spot in the code where I discovered the issue.

What I noticed is that when I compile one of my tests with '-g -O2', replaceTailWIthBranchTo collects LiveRegs from the 'old' basic block that is losing its tail.  That block will eventually jmp to the NewDest basic block.    Some of the registers collected in LiveRegs also happen to be live in the NewDest.liveins.  Because of this correlation (reg is live-in old and live-in new) an IMPLICIT_DEF is generated in the old basic block.   It just happens to be that a DBG_VALUE is associated to that register.  Sorry, that might have been hard to follow.  Here is some generated MI that I noticed differed between the '-O2' and '-g -O2'.  This dump being from '-g -O2'

  bb.11:
  ; predecessors: %bb.10, %bb.12, %bb.14, %bb.16, %bb.18
    successors: %bb.21(0x80000000); %bb.21(200.00%)
    liveins: $rdi
    $al = IMPLICIT_DEF
  
  bb.21 (%ir-block.4):
  ; predecessors: %bb.20, %bb.11
    successors: %bb.22(0x80000000); %bb.22(200.00%)
    liveins: $rdi, $al
    DBG_VALUE debug-use $al, debug-use $noreg, !"d", !DIExpression(), debug-location !36; line no:6
    renamable $ecx = XOR32rr undef $ecx, undef $ecx, implicit-def dead $eflags

In one of my tests, I noticed that a particular basic block (bb.11) was being removed in -O2 but it was not being removed in '-O2 -g', which had an impact on the way the basic blocks were laid out, and resulted  in a code difference.  It appeared that this started from an IMPLICIT_DEF being created  via replaceTailWithBranchTo, which is what is listed in bb.11 above.


https://reviews.llvm.org/D43850