[PATCH] D59431: [DebugInfo] Terminate constant-value location-list ranges at the end of basic blocks

Jeremy Morse via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Mar 22 09:08:38 PDT 2019


jmorse marked 3 inline comments as done.
jmorse added inline comments.


================
Comment at: lib/CodeGen/AsmPrinter/DbgEntityHistoryCalculator.cpp:292
+      }
+      NonRegVars.clear();
     }
----------------
aprantl wrote:
> The title says "constant" but this seems to also affect memory locations. Is that intentional?
It's intentional -- the "location falls through to subsequent blocks" issue described as problem 1 above, also applies to stack spills too. Plus in LiveDebugValues, stack spill DBG_VALUEs weren't propagated between basic blocks either (which this patch patches).

I think I missed it in the title as I was trying to compress what I was saying down into something readable, and wound up cutting out too much, curses.


================
Comment at: lib/CodeGen/LiveDebugValues.cpp:148
+      ImmediateKind,
+      FPImmediateKind,
+      CImmediateKind
----------------
aprantl wrote:
> ConstantFPKind and ConstantIntKind ?
Related to unique-ing, see comment below,


================
Comment at: lib/CodeGen/LiveDebugValues.cpp:223
+        return Var == Other.Var &&
+               Loc.FPImm->isExactlyValue(Other.Loc.FPImm->getValueAPF());
+      else if (Kind == CImmediateKind)
----------------
aprantl wrote:
> The fact that this code exists means that ConstantFP/Ints are not unique?
Hmmmmmm, I'd made the assumption that ConstantFP/Ints aren't unique'd as none of the constructors/static getters took an LLVMContext so couldn't be made unique. Digging further in however shows ConstantInt::get acquires a context through the passed-in type, and do get uniqued. I'll remove this in the next update.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59431/new/

https://reviews.llvm.org/D59431





More information about the llvm-commits mailing list