Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] A question about DBG_VALUE and Frame Index"
2011 Oct 11
1
[LLVMdev] Expected behavior of eliminateFrameIndex() on dbg_value machine instructions
On 10/10/11 19:19, Jakob Stoklund Olesen wrote:
> 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.
>
2012 Mar 08
0
[LLVMdev] A question about DBG_VALUE and Frame Index
On Mar 7, 2012, at 5:19 PM, Pranav Bhandarkar <pranavb at codeaurora.org> wrote:
> Hi,
>
> I have a case that is causing me grief in the form of an assert. The prolog
> Epilog inserter tries to remove Frame Index references. I have a DBG_VALUE
> instruction that looks like this (alongwith the Frame Index). This is for
> the Hexagon backend.
> **************************
2011 Oct 10
2
[LLVMdev] Expected behavior of eliminateFrameIndex() on dbg_value machine instructions
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
2011 Oct 10
0
[LLVMdev] Expected behavior of eliminateFrameIndex() on dbg_value machine instructions
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
2013 Sep 12
1
[LLVMdev] %noreg in DBG_VALUE
I have a question regarding the DBG_VALUE instruction.
IIUC the DBG_VALUE appears in two different forms:
1. DBG_VALUE( %Reg, %Reg, metadata)
2. DBG_VALUE(%Reg, offset, metadata)
In the first version, the second operand is always a %noreg in the form of:
DBG_VALUE(%Reg, %noreg, metadata).
Is it possible to have a different version of DBG_VALUE that only has 2
operands which will have only
2017 Dec 22
0
DBG_VALUE insertion for spills breaks bundles
Hi again,
Here is a small patch to fix this issue. Please note that since the problem results in broken bundles, it can result in invalid schedules for any VLIW back-ends using bundling to group instructions.
Best regards
Saurabh Verma
From: Verma, Saurabh
Sent: Tuesday, December 19, 2017 4:14 PM
To: llvm-dev at lists.llvm.org
Subject: DBG_VALUE insertion for spills breaks bundles
Hi,
The
2017 Dec 19
3
DBG_VALUE insertion for spills breaks bundles
Hi,
The insertion of DBG_VALUE instructions for spills does not seem to be handling insert locations inside bundles well. If the spill instruction is part of a bundle, the new DBG_VALUE is inserted after it, but does not have the bundling flags set. This essentially means that if we start with a set of bundled instructions:
MI1 [BundledSucc=true, BundledPred=false]
MI2 [BundledSucc=false,
2020 Aug 25
3
[Debuginfo] Changing llvm.dbg.value and DBG_VALUE to support multiple location operands
Currently there is a series of patches undergoing review[0] that seek to enable the use of multiple IR/MIR values when describing a source variable's location. The current plan for the MIR is to add a new instruction, DBG_VALUE_LIST, that supports this functionality by having a variable number of operands. It may be better however to simply replace the existing DBG_VALUE behaviour entirely
2020 Sep 02
2
[Debuginfo] Changing llvm.dbg.value and DBG_VALUE to support multiple location operands
> I'm not sure this will work as stated here. Indirectness is (mostly) orthogonal to DW_OP_stack_value. DW_OP_stack_value denotes that we reconstructed the value of the variable, but it doesn't exist in the program ("The DW_OP_stack_value operation specifies that the object does not exist in memory but its value is nonetheless known"), for example, a constant value. I think we
2020 Oct 07
2
[Debuginfo] Changing llvm.dbg.value and DBG_VALUE to support multiple location operands
> I don't see how this is a meaningful distinction in LLVM IR. In LLVM IR we only have SSA values. An SSA value could be an alloca, or a gep into an alloca, or spilled onto the stack at the MIR level, in which case the dbg.value should get lowered into a memory location (if it isn't explicitly a DW_OP_stack_value).
I think the distinction is still important; even at the IR level, if we
2020 Sep 04
2
[Debuginfo] Changing llvm.dbg.value and DBG_VALUE to support multiple location operands
> Yeah, because that decision can only be made much later in LLVM in AsmPrinter/DwarfExpression.cpp.
> In DWARF, DW_OP_reg(x) is a register l-value, all others can either be l-values or r-values depending on whether there is a DW_OP_stack_value/DW_OP_implicit* at the end.
Yes, it might not be clear but that's what I'm trying to say. Out of the non-empty DWARF locations, register and
2012 Apr 10
1
[LLVMdev] Bug in MachineRegisterInfo ?
Hi,
I wanted to see the non-debug uses of register 0 (Noreg) and so, I wrote the
following piece of code.
*****
MRI = &MF.getRegInfo();
if (!MRI->use_nodbg_empty(0)) {
for (MachineRegisterInfo::use_nodbg_iterator
ri = MRI->use_nodbg_begin(0), re = MRI->use_nodbg_end();
ri != re; ++ri) {
MachineInstr *UseMI = &*ri;
UseMI->dump ();
2020 Sep 16
2
[Debuginfo] Changing llvm.dbg.value and DBG_VALUE to support multiple location operands
> That makes sense, and I think for "direct" values in your definition it is true that all direct values are r-values.
> Why do we need DW_OP_LLVM_direct when we already have DW_OP_LLVM_stack_value? Can you give an example of something that is definitely not a stack value, but direct?
The difference in definition is the intention: DW_OP_LLVM_direct means "we'd like this
2020 Oct 06
2
[Debuginfo] Changing llvm.dbg.value and DBG_VALUE to support multiple location operands
> I can see how that could potentially be useful. I'm not sure how often we could practically make use of a situation like this, but I understand your motivation.
Indeed, I don't expect us to cancel out DWARF expressions like that very often. Although that edge case is likely to be very rare, the _direct operator itself will appear very frequently, as it would be used for every
2020 Feb 24
5
[RFC] DebugInfo: A different way of specifying variable locations post-isel
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
2008 Jul 16
2
[LLVMdev] instcombine Question
I see instcombine doing something I'm not sure is right.
Incoming, I have this:
%r29 = ptrtoint [71 x i64]* %"t$3" to i64 ; <i64> [#uses=1]
%r30 = inttoptr i64 %r29 to i64* ; <i64*> [#uses=1]
store i64 72057594037927936, i64* %r30, align 8
Outgoing, I have this:
%r30 = getelementptr [71 x i64]* %"t$3", i32 0, i32 0 ; <i64*> [#uses=1]
store i64
2012 Sep 03
0
[LLVMdev] DBG_VALUE instruction format and generation
+llvmdev
-llvm-commits
Hi!
I've got the following questions about DBG_VALUE instruction:
1) When I dump this instruction I see the line of the form:
DBG_VALUE %EDI, 0, !"a"; line no:47
for two completely different cases:
* when value of "a" is actually stored in a register %edi (this should
be encoded as "DW_OP_reg5" in DWARF).
* when value of
2020 Feb 25
2
[RFC] DebugInfo: A different way of specifying variable locations post-isel
Hi Vedant, thanks for the detailed response,
On Tue, Feb 25, 2020 at 7:23 AM Vedant Kumar <vedant_kumar at apple.com> wrote:
> > Finally, being forced to always specify both the machine location and
> > the program location at the same time (in a single DBG_VALUE)
> > introduces un-necessary burdens. In MachineSink, when we sink between
> > blocks an instruction that
2017 Sep 07
5
RFC: Unify debug and optimized variable locations with llvm.dbg.addr [was: DW_OP_LLVM_memory]
I chatted with Chandler in person and came up with what I think is a much
simpler design than my previous design in the thread titled "RFC: Introduce
DW_OP_LLVM_memory to describe variables in memory with dbg.value".
The crux of the problem in that thread is that we need a representation,
particularly in the middle-end, to describe a variables address, at a
particular program point.
2015 Jun 23
4
[LLVMdev] Improving the quality of debug locations / DbgValueHistoryCalculator
Here is a proposal for improving DbgValueHistoryCalculator and the
overall quality of debug locations.
Focus: This is about lowering the DBG_VALUE machine instructions to
DWARF location lists.
Non-focus: This is not about (typical -O0) variables that permanently
reside at a frame index and are described with dbg.declare intrinsics
in the IR. These variables are stored in the MMI side-table and