search for: dw_op_stack_valu

...; 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 to be an l-value if possible", DW_OP_stack_value means "this should never be an l-value". Because of this, an expression ending with DW_OP_LLVM_direct can be emitted as an l-value in any case where the value of the preceding expression is equal to an l-value. So for example: DBG_VALUE $rsp, !"x", !DIExpression(DW_OP_LLVM_d...

...ev 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 for LLVM’s dbg.value. We could hypothetically >> repurpose DW_OP_stack_value to indicate that the SSA value passed to >> llvm.dbg.value *is* the variable’s value, and if the expression lacks >> DW_OP_stack_value, it must be a the address of the value. However, that is >> backwards incompatible and it seems like quite a stretch. >> > > Seems li...

> 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 want so...

> 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 memory locations are l-values, implicit locations are r-values. You can technically use DW_OP_breg in an l-value, but not for register locations. Th...

...t;>> To support that, all existing uses would need no changes to match the >>> DWARF model of registers being implicitly direct values. >>> >>> Code that wanted to describe the register as containing the memory >>> address of the interesting thing would use DW_OP_stack_value to say "this >>> location description that is a register is really an address you should >>> follow to find the value, not a direct value itself"? >>> >>> But code that wanted to describe a variable as being 3 bytes ahead of a >>> pointer in a...

...d so I'm looking for any comments on this change before pushing ahead with it. There are a few differences between the MIR instructions: Old: DBG_VALUE %x, $noreg, !DILocalVariable("x"), !DIExpression() New: DBG_VALUE !DILocalVariable("x"), !DIExpression(DW_OP_LLVM_arg, 0, DW_OP_stack_value), %x 1) The "location" operand is moved to the end, as the instruction is now variadic such that every operand after the DIExpression is a location operand. 2) The second operand which currently represents "Indirectness" has been removed entirely, because this is now explicitl...

...n a debugger begins evaluating a DWARF expression, it assumes that the resulting value will be a pointer to the variable in memory. For a debugger, this makes sense, because debug builds put things in memory and even after optimization many variables must be spilled. Only the special DW_OP_regN and DW_OP_stack_value expression opcodes change the location of the value from memory to register or stack value. 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 for LLVM’s dbg.value. We could hyp...

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

...WARF. 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 as DW_OP_regx. You also have DW_OP_stack_value to say "just kidding, this location expression is a value expression." So, whether we want to start throwing around deref or stack_value or regx (implicit or explicit) really depends on whether we are going to be using value expressions or location expressions. Let's not start mixin...

...t is not the address, and we typically use empty DIExpressions. If >>>> the value is ultimately register allocated and the DIExpression is empty, >>>> we will emit a DW_OP_regN location expression. If the value is spilled, we >>>> usually don't need to append DW_OP_stack_value because the location is now >>>> a memory location, which can be described by DW_OP_[f]breg. >>>> >>>> Today, passes that want to add "plus 3" to a DIExpression go out of >>>> their way to add DW_OP_stack_value to the DIExpression because t...

> 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 I will experiment with that. In general though and for the future it seems that it would be of benefit to h...

...s, we can safely say that any expression that isn't _direct, implicit, or empty will be a memory location. So for the first expression we would check to see if it could be emitted as a register location, and when that fails we emit a stack value: DW_OP_breg7 RSP+0, DW_OP_constu 4, DW_OP_minus, DW_OP_stack_value Since the second expression is not LLVM_direct, stack_value, implicit_ptr, or any other explicitly declared location type, then it must be a memory location, so we emit: DW_OP_breg7 RSP+0, DW_OP_constu 4, DW_OP_minus -------------- next part -------------- An HTML attachment was scrubbed... URL:...

...ignoring any fragment operator, which may appear at the end but does not affect the location type): 1. If the expression is empty, or any location arguments are $noreg => Empty 2. If the expression ends with DW_OP_implicit_ptr => Implicit pointer (rvalue) 3. If the expression ends with DW_OP_stack_value =>Stack value (rvalue) // LLVM should produce LLVM_direct instead. 4. If the expression ends with DW_OP_LLVM_direct, then... 4a. If the preceding expression is just DW_OP_LLVM_arg, 0 and the only location operand is a register => Register location (lvalue) 4b. Otherwise => Stac...

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

...resentation is sufficient for all other locations, and ideally the indirectness flag would have no effect (although unfortunately it does). The justification for DW_OP_LLVM_direct rests on the idea that we will generally choose to produce "DW_OP_reg7 RSP" instead of "DW_OP_breg7 RSP, DW_OP_stack_value". It doesn't prevent us from using DW_OP_stack_value instead if we have an exception, but I don't believe there are any. Using DW_OP_LLVM_direct instead of directness and stackval for the table above, we get this: (plus_uconst, 8), -> DW_OP_breg7 RSP+8...

...on'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 have a dbg.value that uses an alloca or something similar, we can still distinguish between "this alloca is the variable's location" versus "this alloca is the variable's value", i.e. the variabl...

...!22 } The value of the variable c when on the return statement is always incorrectly reported as being the value 2. The generated DWARF location list for the variable c looks something like (the offset 00000038 is beyond the end of the function): 00000013 00000004 00000024 (DW_OP_consts: 1; DW_OP_stack_value) 00000020 00000024 00000038 (DW_OP_consts: 2; DW_OP_stack_value) I know what is wrong, I thought! After the phi instruction there should be an @llvm.dbg.value call which describes the variable c as having the value returned by the phi, so I manually altered the IR to the following, thinkin...

...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: !DIExpression(DW_OP_constu, 44, DW_OP_stack_value)) Why DIExpression is mostly empty? -- Regards, Peng

...n a debugger begins evaluating a DWARF expression, it assumes that the resulting value will be a pointer to the variable in memory. For a debugger, this makes sense, because debug builds put things in memory and even after optimization many variables must be spilled. Only the special DW_OP_regN and DW_OP_stack_value expression opcodes change the location of the value from memory to register or stack value. 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 for LLVM’s dbg.value. We could hyp...

...1 %15 = getelementptr inbounds i32, i32* %11, i64 %14, !dbg !48 %16 = trunc i64 %14 to i32, !dbg !49 store i32 %16, i32* %15, align 4, !dbg !49, !tbaa !33 %17 = add nuw nsw i64 %14, 1, !dbg !50 call void @llvm.dbg.value(metadata i32 undef, metadata !26, metadata ! DIExpression(DW_OP_plus_uconst, 1, DW_OP_stack_value)), !dbg !41 %18 = load i32, i32* %8, align 4, !dbg !51, !tbaa !52 %19 = sext i32 %18 to i64, !dbg !42 %20 = icmp slt i64 %17, %19, !dbg !42 br i1 %20, label %13, label %12, !dbg !44, !llvm.loop !54 } --Snip--- Question is why the load IR and sext IR (obj.a) is not getting hoisted out of the loop...