search for: livedebugvari

...eduling passes would become significantly > > easier to deal with: they would only have to replace DBG_VALUE > > instructions in the correct order, not worry about their operands. > > Various debug facilities in SimpleRegisterCoalescing, MachineSink, and > > large amounts of LiveDebugVariables would become redundant, as we > > wouldn't need to maintain a register location through optimisations. > > I view this as a very large potential upside. LiveDebugVariables is incredibly complex and is a huge compile-time bear. Defining away large chunks of its job would be real...

...// Seems still works here. (not "drop the DBG_VALUE ") > 400B $eax = COPY %17:gr32, debug-location !51; phi.ll:23:1 > 416B RETQ implicit killed $eax, debug-location !51; phi.ll:23:1 > ____________________________________________________ Indeed; it's LiveDebugVariables that drops out-of-liveness DBG_VALUEs, as seen here: https://github.com/llvm/llvm-project/blob/68ac02c0dd2b8fda52ac132a86f72f2ad6b139a5/llvm/lib/CodeGen/LiveDebugVariables.cpp#L657 as the register allocator will not maintain the location of its vreg for positions that aren't live. --...

...tions with just a FrameIndex operand followed by the mandatory Offset and Metadata operands. This behavior doesn't match the comment above TII::emitFrameIndexDebugValue() which says "For targets that do not support this the debug info is simply lost". In UserValue::insertDebugValue in LiveDebugVariables.cpp if emitFrameIndexDebugValue returns 0 then it adds a DBG_VALUE with the standard operands. However in other places where emitFrameIndexDebugValue is called it appears to removes the debug value (e.g. in InlineSpiller::spillAroundUses()). Should the comment be updated or is the code in Live...

...he conversation, but if it is causing confusion rather than making the discussion flow easier, then we better ignore it. The whole triggering point for this email initiative is - one of the applications is crashing with the stack trace that I mentioned earlier. The crash is during the pass - llvm::LiveDebugVariables::runOnMachineFunction(). And, it is because, the function in question is `optimized` case, and hence `unit` is `null', and we are accessing this `null` pointer at the point of crashing. Naturally, I want to understand the root of this issue. So, many questions are raised within my mind....

...assignments. The three instruction scheduling passes would become significantly easier to deal with: they would only have to replace DBG_VALUE instructions in the correct order, not worry about their operands. Various debug facilities in SimpleRegisterCoalescing, MachineSink, and large amounts of LiveDebugVariables would become redundant, as we wouldn't need to maintain a register location through optimisations. Finally, this design could be extended to not having any instructions in the instruction stream. Once machine locations aren't described within a MachineOperand, the most important thing...

On Oct 10, 2011, at 10:26 AM, Richard Osborne wrote: > I'm investigating a bug associated with debug information that manifests > itself in the XCore backend (PR11105). I'd like to understand what the > expected behavior of eliminateFrameIndex() is when it is called on a > dbg_value machine instruction. That is up to the target. The TII::emitFrameIndexDebugValue() hook is

I'm investigating a bug associated with debug information that manifests itself in the XCore backend (PR11105). I'd like to understand what the expected behavior of eliminateFrameIndex() is when it is called on a dbg_value machine instruction. Currently the XCore target replaces the frame index with the frame register and sets the next operand to the byte offset from the frame

...> (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) > >> > #4 0x0000556016f013ea > >> > llvm::LexicalScopes::initialize(llvm::MachineFunction const&) > >> > (/opt/rocm/llvm/bin/llc+0xd5a3ea) > >> > #5 0x0000556016f224dd > >> > llvm::LiveDebugVariables::runOnMachineFunction(llvm::MachineFunction&) > >> > (/opt/rocm/llvm/bin/llc+0xd7b4dd) > >> > #6 0x0000556016fcb2b0 > >> > llvm::MachineFunctionPass::runOnFunction(llvm::Function&) > >> > (/opt/rocm/llvm/bin/llc+0xe242b0) > >> &...

...017a289a3 SignalHandler(int) (/opt/rocm/llvm/bin/llc+0x18819a3) #3 0x00007fdb38654890 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) #4 0x0000556016f013ea llvm::LexicalScopes::initialize(llvm::MachineFunction const&) (/opt/rocm/llvm/bin/llc+0xd5a3ea) #5 0x0000556016f224dd llvm::LiveDebugVariables::runOnMachineFunction(llvm::MachineFunction&) (/opt/rocm/llvm/bin/llc+0xd7b4dd) #6 0x0000556016fcb2b0 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/opt/rocm/llvm/bin/llc+0xe242b0) #7 0x0000556017375e8f llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/rocm/l...

I have been investigating missing variables / incorrect variable values when debugging code compiled at -O1 (and above) and believe that I have tracked the issue down to the interaction of the generation of IR @llvm.dbg.value entries and phi nodes. I would welcome someone who is more familiar with the generation of debug information to help me determine if what I think is going wrong is correct

...gt; #3 0x00007fdb38654890 __restore_rt > > (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) > > #4 0x0000556016f013ea > > llvm::LexicalScopes::initialize(llvm::MachineFunction const&) > > (/opt/rocm/llvm/bin/llc+0xd5a3ea) > > #5 0x0000556016f224dd > > llvm::LiveDebugVariables::runOnMachineFunction(llvm::MachineFunction&) > > (/opt/rocm/llvm/bin/llc+0xd7b4dd) > > #6 0x0000556016fcb2b0 > > llvm::MachineFunctionPass::runOnFunction(llvm::Function&) > > (/opt/rocm/llvm/bin/llc+0xe242b0) > > #7 0x0000556017375e8f > > llvm::FP...

...for the new/dropped location in the reduced and original file, as llvm-reducing them can alter the reason why something is dropped or not. Of the new locations, we previously could not track the location because: * 14 DBG_VALUEs come after the vreg operand is out of liveness and are dropped by LiveDebugVariables. * 2 DBG_VALUEs are out of liveness and dropped by RegisterCoalescing out of conservativeness. * 2 DBG_VALUEs that appear before their operand is defined. This is out of liveness, instruction referencing saves them through preserving debug use-before-defs. * 2 DBG_VALUEs that are o...

...tion in the > reduced and original file, as llvm-reducing them can alter the reason why > something is dropped or not. Of the new locations, we previously could not > track the location because: > * 14 DBG_VALUEs come after the vreg operand is out of liveness and are dropped > by LiveDebugVariables. > * 2 DBG_VALUEs are out of liveness and dropped by RegisterCoalescing > out of conservativeness. > * 2 DBG_VALUEs that appear before their operand is defined. This is out of > liveness, instruction referencing saves them through preserving debug > use-before-defs. &...

Hi All, I am observing something i suspect is a misbehaviour of the register allocator which impacts the performance of patchpoints. This occurs in the context of an abstract machine which in some places uses inline caches. The problematic code looks like this: entry: ; Initialize the abstract machine %db = call create_big_seldom_used_database() ; do a lot of things which increases register

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

...build llvm[3]: Building Release+Asserts Archive Library libLLVMMCParser.a make[3]: Leaving directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/MC/MCParser' llvm[2]: Compiling ConstantPools.cpp for Release+Asserts build llvm[2]: Compiling COFFYAML.cpp for Release+Asserts build llvm[2]: Compiling LiveDebugVariables.cpp for Release+Asserts build llvm[2]: Compiling Option.cpp for Release+Asserts build llvm[2]: Compiling ELFObjectWriter.cpp for Release+Asserts build llvm[2]: Building Release+Asserts Archive Library libLLVMOption.a make[2]: Leaving directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/Option...