search for: varloc

...gt; > Do you expect that handling for the current and new-style DBG_VALUEs could coexist in LiveDebugValues? Could that be done by e.g. introducing a new debug instr MI (DBG_INSTR_REF)? I believe it should be relatively straightforwards: we would have an additional kind of location-record (i.e. VarLoc) that, instead of identifying a _variable_, identified the instruction/operand that computed a value. Handling a DBG_INSTR_REF as you suggest would mean looking up such a VarLoc by instruction/operand to find its register, then creating a register location VarLoc for the variable as we do today. Pr...

...e you don't really init all the info to bottom for real. It tries to be lazy. Otherwise, they'd all have outlocs of bottom. They are only theoretically initialized, so things get the wrong answer. For example, this code is not right: // For all predecessors of this MBB, find the set of VarLocs that // can be joined. for (auto p : MBB.predecessors()) { auto OL = OutLocs.find(p); // Join is null in case of empty OutLocs from any of the pred. if (OL == OutLocs.end()) return false; This is wrong if the block is unvisited (as you say) -------------- next part -------...

> On Sep 21, 2016, at 2:23 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > > // For all predecessors of this MBB, find the set of VarLocs that > // can be joined. > for (auto p : MBB.predecessors()) { > auto OL = OutLocs.find(p); > // Join is null in case of empty OutLocs from any of the pred. > if (OL == OutLocs.end()) > return false; > > > This is wrong if the block is unvisited...

...= Conditional jump or move depends on uninitialised value(s) ==27195== at 0x56A0917: (anonymous namespace)::LiveDebugValues::transferDebugValue(llvm::MachineInstr const&, (anonymous namespace)::LiveDebugValues::OpenRangesSet&, llvm::UniqueVector<(anonymous namespace)::LiveDebugValues::VarLoc>&) [clone .isra.207] (in /nix/store/06dpmfn74zrmman8nq8p96dg50lwbxhg-llvm-3.9.0-lib/lib/ libLLVM-3.9.so) ==27195== by 0x56A3EE5: (anonymous namespace)::LiveDebugValues::ExtendRanges(llvm::MachineFunction&) [clone .constprop.259] (in /nix/store/06dpmfn74zrmman8nq8p96dg50lwbxhg-llvm-3.9...

...ion; instead they preserved an undef debug instruction in early-taildup, and my scripts picked this up as dropping a location. * 2 locations aren't tracked by InstrRefBasedLDV through a block that's out of scope, meaning the location never covers instructions that are in scope. VarLocBasedLDV is vulerable to this too, but MachineSink can drop a DBG_VALUE on the far side of the scope gap, saving the location. See "Limitations" below. * 2 locations dropped during tail duplication: one in early-taildup which I haven't tried to address yet (see "Limitati...

...preserved an undef debug instruction in early-taildup, and my scripts picked > this up as dropping a location. > * 2 locations aren't tracked by InstrRefBasedLDV through a block that's > out of scope, meaning the location never covers instructions that are in > scope. VarLocBasedLDV is vulerable to this too, but MachineSink can drop a > DBG_VALUE on the far side of the scope gap, saving the location. See > "Limitations" below. > * 2 locations dropped during tail duplication: one in early-taildup which > I haven't tried to address yet...

Adrian, I am currently investigating issues where variables that one would expect to be available in a debugger are not in code that is compiled at optimisations other than -O0 The main problem appears to be with the LiveDebugValues::join() method because it does not allow variables to be propagated into blocks unless all predecessor blocks have an Outgoing Location for that variable. As a

Hi debuginfo-cabal, tl;dr: Let's please consider using a new implementation of LiveDebugValues that produces richer information, might be slightly faster, but mostly will support the instruction referencing and value tracking paradigm from my RFC [0] rather than the location tracking that LiveDebugValues does today. In that RFC, the main motivator is to treat variable locations a bit more

Hi debuginfo cabal, tl;dr: I'd like to know what people think about an alternative to DBG_VALUE instructions describing variable locations in registers, virtual or real. Before instruction selection in LLVM-IR we identify the _values_ of variables [0] by the instruction that computes the value; I believe we should be able to do the same post-isel, and it would avoid having to analyse register