[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