search for: dw_op_stack_values

Displaying 20 results from an estimated 33 matches for "dw_op_stack_values".

Did you mean: dw_op_stack_value
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
2017 Sep 06
4
RFC: Introduce DW_OP_LLVM_memory to describe variables in memory with dbg.value
On Wed, Sep 6, 2017 at 10:01 AM, David Blaikie <dblaikie at gmail.com> wrote: > On Tue, Sep 5, 2017 at 1:00 PM Reid Kleckner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> LLVM SSA values obviously do not have an address that we can take and >> they don’t live in registers, so neither the default memory location model >> nor DW_OP_regN make sense
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 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
2017 Sep 07
2
RFC: Introduce DW_OP_LLVM_memory to describe variables in memory with dbg.value
On Wed, Sep 6, 2017 at 5:01 PM, David Blaikie <dblaikie at gmail.com> wrote: > On Wed, Sep 6, 2017 at 2:01 PM Reid Kleckner <rnk at google.com> wrote: > >> On Wed, Sep 6, 2017 at 10:01 AM, David Blaikie <dblaikie at gmail.com> >> wrote: >> >>> I guess you described this already, but talking it through for >>> myself/maybe others will
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
2017 Sep 05
7
RFC: Introduce DW_OP_LLVM_memory to describe variables in memory with dbg.value
Debug info today handles two cases reasonably well: 1. At -O0, dbg.declare does a good job describing variables that live at some known stack offset 2. With optimizations, variables promoted to SSA can be described with dbg.value This leaves behind a large hole in our optimized debug info: variables that cannot be promoted, typically because they are address-taken. This is
2020 Sep 15
2
[Debuginfo] Changing llvm.dbg.value and DBG_VALUE to support multiple location operands
Hi Adrian & Stephen, One thought here: But — not all memory locations are l-values. If we have a DWARF location list for variable "x" which points to a memory address for the first n instructions and the switches to a constant for the remainder of the scope, the memory address is not guaranteed to be an l-value, because writing the the memory address cannot affect the later part of
2017 Sep 06
2
RFC: Introduce DW_OP_LLVM_memory to describe variables in memory with dbg.value
It's worth remembering that there are two syntactically similar but semantically different kinds of "expression" in DWARF. A DWARF expression computes a value; if the available value is a pointer, you add DW_OP_deref to express the pointed-to value. A DWARF location expression computes a location, and adds various operators to express locations that a (value) expression cannot, such
2017 Sep 07
2
RFC: Introduce DW_OP_LLVM_memory to describe variables in memory with dbg.value
On Thu, Sep 7, 2017 at 9:46 AM, David Blaikie <dblaikie at gmail.com> wrote: > Feels to me like bugs rather than inconsistencies (I'd think of an > inconsistency as "we do X over here intentionally and Y over here > intentionally but they're in contradiction to one another") > The DBG_VALUE MachineInstr actually already has a way to indicate that the computed
2019 Jan 25
2
Concatenating DWARF location expressions
> From: aprantl at apple.com <aprantl at apple.com> > Since it sounds like the problem is only with implicit descriptions, would a rule > such as "if the expression has a DW_OP_stack_value, add an extra > DW_OP_deref" work for the PrologueEpilgueInserter or do we need > something more principled? Right, that could very well be sufficient for this particular case so
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 Sep 11
2
[Debuginfo] Changing llvm.dbg.value and DBG_VALUE to support multiple location operands
> Can you elaborate what "direct" means? I'm having trouble understanding what the opposite (a non-exact value) would be. Apologies, "exact" was a misleading/incorrect term. By direct, I mean that the expression computes the value of the variable, as opposed to its memory address, or the value that it points to. Within LLVM, where we don't have DW_OP_reg/DW_OP_breg
2019 Jan 24
2
Concatenating DWARF location expressions
Hello, Could someone explain to me what the rules are for concatenation of DWARF location expressions? For example in lib/CodeGen/PrologEpilogInserter.cpp there is a call to DIExpression::prepend to concatenate the stack slot address of a variable to an existing expression. Now the problem here is that the former is a 'Memory location description' while the latter could very well be a
2020 Sep 15
2
[Debuginfo] Changing llvm.dbg.value and DBG_VALUE to support multiple location operands
> That sounds to me to be the same concept that I am calling r-value vs. l-value. Do you agree, or is there some subtlety that I am missing? I've been assuming that the l-value vs r-value distinction is analogous to C++: an l-value can be written to by the debugger, an r-value cannot. A memory location and a register location are both l-values, while implicit locations (stack
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
2016 Jul 29
3
IR @llvm.dbg.value entries for variables when a phi node has been created
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
2019 Jan 20
3
DIGlobalVariableExpression doc in langref
Hi, I don't find DIGlobalVariableExpression in langref. Should it be documented? Could anybody explain what it is? https://llvm.org/docs/LangRef.html In one ll file converted from bitcode, I mostly see something like this. !8273 = !DIGlobalVariableExpression(var: !8274, expr: !DIExpression()) Only one looks like this. !8945 = !DIGlobalVariableExpression(var: !8946, expr:
2017 Sep 05
2
RFC: Introduce DW_OP_LLVM_memory to describe variables in memory with dbg.value
Hi Reid, Thanks for taking this on, I'm very pleased to see improvements related to debug info for optimized code. (You can cc me on code reviews, although I'm sure a lot of the patches will be in areas I am not very familiar with.) While I have a really good handle on the DWARF standard, and have done a bunch of work with the type stuff, my understanding of IR mechanics is pretty naïve,
2019 Jul 08
4
Question on Aliasing and invariant load hoisting
Hi, I have the below test case. --snip-- struct st { int a; int b; }; int * ptr; int x,y; void bar(int *x); void foo() { struct st obj; bar(&obj.b); if(x) obj.a =x; else obj.a =y; for (int i=0; i<obj.a;i++) ptr[i]=i; } --snip-- LLVM IR produced at -O3 is shown below. ref: https://godbolt.org/z/WPlmfr --Snip-- %8 = getelementptr inbounds %struct.st,