search for: diexpressions

...might be worth migrating to that first (basically adding DW_OP_LLVM_register(0) at the start of every DIExpression) and then expanding it from unary to n-ary support Putting the register values initially on the stack reduces the verbosity, though it could complicate successive salvages of variadic DIExpressions - if any value other than the last needs salvaging, then you have to use DWARF stack operations to move it to the top of the stack. For example, if the elements are pushed in order so that the last element is on the top of the stack: %c = mul 3, %a %d = add 5, %b dbg.value(!DILocalVariable("x...

...eady, but talking it through for > myself/maybe others will find this useful: > > So since we don't have DW_OP_regN for LLVM registers, we could sort of > assume the implicit first value on the stack is a pseudo-OP_regN of the > LLVM SSA register. > Yep, that's how we use DIExpressions in both IR and MIR: The LHS of the dbg.value and DBG_VALUE instructions are a register-like value that gets pushed onto the expression stack. The DWARF asmprinter does some expression folding to clean things up, but that's the model. > To support that, all existing uses would need no chang...

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

...in this code are analogous to if we had "a = bar() + 4 - 4;", but because we don't figure out that "a = bar()" in a single pass, we pre-emptively assume that "a" must be an r-value. To be able to emit an l-value we would first need the ability to optimize/simplify DIExpressions so that the expression becomes just (DW_OP_stack_value) - this wouldn't be particularly difficult to implement for simple arithmetic. Even with this improvement, the definition of DW_OP_stack_value explicitly forbids the expression from being a register location. If we instead used DW_OP_LLVM_d...

> On Nov 18, 2019, at 8:33 AM, Jeremy Morse <jeremy.morse.llvm at gmail.com> wrote: > > Hi llvm-dev@, > > Switching focus to the LLVM implementation, the significant change is > using dbg.value's first operand to refer to a DILocalVariable, rather > than a Value. There's some impedance mismatch here, because all the > documentation (for example in the

*From:* flang-dev <flang-dev-bounces at lists.flang-compiler.org> *On Behalf Of *Eric Schweitz (PGI) *Sent:* Thursday, November 01, 2018 1:02 PM *To:* flang-dev at lists.flang-compiler.org *Subject:* [Flang-dev] RFC: Adding debug information to LLVM to support Fortran In order to support debugging in the Flang project, work has been done to extend LLVM debug information for the Fortran

...will find this useful: >>> >>> So since we don't have DW_OP_regN for LLVM registers, we could sort of >>> assume the implicit first value on the stack is a pseudo-OP_regN of the >>> LLVM SSA register. >>> >> >> Yep, that's how we use DIExpressions in both IR and MIR: The LHS of the >> dbg.value and DBG_VALUE instructions are a register-like value that gets >> pushed onto the expression stack. The DWARF asmprinter does some expression >> folding to clean things up, but that's the model. >> >> >>> To...

...also deleted at which point there is not much that can be done with the current scheme. One idea for how to address this would be that, since LSR is a SCEV based optimization, one could perform additional debug salvaging by comparing SCEV expressions for the new and old PHI-node and then adjusting DIExpressions if they match with an offset. Any thoughts on that? -Markus --- *** IR Dump After Canonicalize Freeze Instructions in Loops *** ; Preheader: entry: call void @llvm.dbg.value(metadata i8* %p, metadata <0x111daf20>, metadata !DIExpression()), !dbg !DILocation(line: 0, scope: <0x111d4030&...

...same effect can be achieved by implicitly pushing all operands of a DBG_VALUE to the stack, followed by a combination of DW_OP_dup, DW_OP_pick, DW_OP_swap, DW_OP_rot, and DW_OP_over. However, the resulting expressions can get very long and unwieldy and it is easier to generate efficient DWARF from DIExpressions that explicitly refer to arguments. DW_OP_LLVM_argN has the advantage of using less memory, at the cost of limiting the number of arguments to a hardcoded value. > > > > I'd also add that since `DW_OP_pick N` picks the Nth argument from the top of the stack rather than the bottom, u...

...same effect can be achieved by implicitly pushing all operands of a DBG_VALUE to the stack, followed by a combination of DW_OP_dup, DW_OP_pick, DW_OP_swap, DW_OP_rot, and DW_OP_over. However, the resulting expressions can get very long and unwieldy and it is easier to generate efficient DWARF from DIExpressions that explicitly refer to arguments. DW_OP_LLVM_argN has the advantage of using less memory, at the cost of limiting the number of arguments to a hardcoded value. > >>> > >>> I'd also add that since `DW_OP_pick N` picks the Nth argument from the top of the stack rather th...

Currently, the debug intrinsic functions each have 3 arguments: an SSA value representing either the address or Value of a local variable, a DILocalVariable, and a complex expression. If the SSA value is an Instruction, and that Instruction is at some point deleted, we attempt to salvage the SSA value by recreating the instruction within the complex expression. If the instruction cannot be

The frontend code is a pretty simple for loop, that counts from i = 0; i != 10; i += 1 It gets optimized into and endless loop. export fn entry() void { var array: [10]Bar = undefined; var x = for (array) |elem, i| { if (i == 1) break elem; } else bar2(); } Here's the generated IR: ; ModuleID = 'test' source_filename = "test" target datalayout =

> 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

> I don't have a strong opinion on representation. I can see how having a dedicated instruction to model implicit pointers would aid readability & be simpler to document/grok, but perhaps in the future we'll want to support other operations that refer to variable > DIEs. In the short term migrating to an extended dbg.value representation might take more work. Alok, wdyt? Below

On Tue, Jan 5, 2016 at 6:59 PM, Adrian Prantl <aprantl at apple.com> wrote: > Thanks for the clarification, Paul! > Keno, just a few more questions for my understanding: > > > - Indicating that a value changed at source level (e.g. because an > > assignment occurred) > > This is done by a key call. Correct > > - Indicating that the same

>As the person who has advocated for DW_OP_LLVM_arg(N) before, my main motivation was to resolve the ambiguity of constant DIExpressions: As a worst-case example: > >dbg.value(%undef, !DILocalVariable(x), DIExpression(DW_OP_constu, 42)) > >Is this undefined, or constant 42? > >But if we make dbg.value fully variadic with all parameters pushed to the stack ahead of time, we can distinguish between > >dbg.value...

...xample, a constant value. I think we want something like DW_OP_deref instead, at least for r-values. For l-values (=variables a debugger could write to) we would need to have a discriminator that declares the DBG_VALUE as a memory location (cf. DWARF5 chapter 2.6). This is a tricky one. Right now, DIExpressions sort-of mimic DWARF, but with differences that aren't always immediately clear. The reason why I chose DW_OP_stack_value for the direct-value-case instead of using DW_OP_deref for the indirect-value-case is that it is more like actual DWARF: a DWARF expression is either empty, a register, a mem...

...icit locations (stack value/implicit pointer) are r-values. Directness on the other hand, I've been using to mean "the variable's value is equal to the value computed by the DIExpression". Applied to a DWARF expression this description would only refer to a stack value. LLVM's DIExpressions are different however, because we don't have DW_OP_reg or DW_OP_breg: we simply refer to the register and use context to determine which it should be. The best example of this is from this example[0], expanded on here with the location type: $noreg, (plus_uconst, 8), -> DW_OP...

Adrian, Thanks for a quick reply! On Thu, Mar 22, 2018 at 4:22 PM, Adrian Prantl <aprantl at apple.com> wrote: > > >> On Mar 22, 2018, at 4:08 PM, Roman Levenstein <romixlev at gmail.com> wrote: >> >> Hi, >> >> I'm trying to achieve the following: >> >> - I have a global variable BaseAddress that holds the base address of >> a

> 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