[PATCH] D11933: Extending debug ranges

Adrian Prantl via llvm-commits llvm-commits at lists.llvm.org
Mon Aug 24 16:24:45 PDT 2015


aprantl added a comment.

In http://reviews.llvm.org/D11933#225701, @tvvikram wrote:

> I compiled your test case with clang -O1 and here is the input to DBG_VALUE fixup pass (output of StackMapLivenessAnalysis).




> The DBG_VALUE instr for "x" is already present in BB#2 and only "x" in RDI got propagated to BB#1.


Looking into this I found that LiveDebugVariables is the culprit here:

  void UserValue::extendDef(SlotIndex Idx, unsigned LocNo,
                            LiveRange *LR, const VNInfo *VNI,
                            SmallVectorImpl<SlotIndex> *Kills,
                            LiveIntervals &LIS, MachineDominatorTree &MDT,
                            UserValueScopes &UVS) {
      ...
      for (unsigned i = 0, e = Children.size(); i != e; ++i) {
        MachineBasicBlock *MBB = Children[i]->getBlock();
        if (UVS.dominates(MBB))
          Todo.push_back(LIS.getMBBStartIdx(MBB));
    }
  }

It look like it just unconditionally propagates all DBG_VALUEs down the dominator tree, which happens to work fine if there already is another DBG_VALUE but is wrong if the DBG_VALUE is coming from only one of the predecessors like in this example here.

I filed this as PR24563 (https://llvm.org/bugs/show_bug.cgi?id=24563).

> With respect to handling variables having constant value, an early thought is to have ranges for them until the variable is moved to register. When the variable is moved to register, it will end all previous ranges of that variable because the move to register will mean that it may be operated on and the value may change. The current patch handles only register locations.


That sounds reasonable. Memory locations should be treated similarly, too.


http://reviews.llvm.org/D11933





More information about the llvm-commits mailing list