similar to: Proposal for multi location debug info support in LLVM IR

Adrian had proposed the following staging: 1. Remove offset argument from dbg.value 2. Unify dbg.value and dbg.declare 3. Full implementation I'm not yet sure what to do about the difference in dbg.declare semantics. For example, i think the following currently works ``` top: %x = alloca br else if: dbg.declare(%x... unreachable else: # dbg.declare still applies here ``` I think it would

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

Thanks for your comments. Replies inline. > The DWARF 5 standard says that > "Address range entries in a range list may not overlap.” > > The reasoning behind this is presumably that if a variable is in more than > one > location at a point all the values need to be identical, or the > information is useless Oh huh, for some reason I was under the impression that they

Hi! I created a bug report (https://llvm.org/bugs/show_bug.cgi?id=23712) for this failure but then I realized that my approach may be wrong. The following D source contains a lazy variable: void bar(lazy bool val) { val(); } The lazy variable val is translated to a delegate. The signature and the first IR lines are: define void @_D7opover23barFLbZv({ i8*, i1 (i8*)* } %val_arg) #0 {

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

I'm going to show the same function, first normally, and then as a coroutine, and show how gdb can see the variable when it's a normal function, but not when it's a coroutine. I'd like to understand if this can be improved. I'm trying to debug a real world problem, but the lack of debug info on variables in coroutines is making it difficult. Should I file a bug? Is this a

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

> 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

What would it look like without this extension? If we modeled it as if all the register values were already on the stack (an extension of the current way where the singular value is modeled as being already on the stack, if I understand it correctly?)? If it's decided that the best approach is to introduce something like DW_OP_LLVM_register - might be worth migrating to that first (basically

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

>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

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,

> 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

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 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

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

On Wed, Sep 19, 2018 at 5:18 PM Adrian Prantl <aprantl at apple.com> wrote: > > > > > On Sep 19, 2018, at 4:08 AM, Alexander Potapenko <glider at google.com> wrote: > > > > On Tue, Sep 18, 2018 at 1:56 AM Adrian Prantl <aprantl at apple.com> wrote: > >> > >> > >> > >>> On Sep 17, 2018, at 6:59 AM, Alexander

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

> 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

I'm interested in using @llvm.experimental.vector.reduce.smax/umax to implement runtime overflow checking for vectors. Here's an example checked addition, without vectors, and then I'll follow the example with what I would do for checked addition with vectors. Frontend code (zig): export fn entry() void { var a: i32 = 1; var b: i32 = 2; var x = a + b; } LLVM IR code: