search for: dilocalvari

Hi all, I'm dealing with LLVM's debug information metadata, and have run into an interesting edge case. Under normal circumstances, every `DILocalVariable` has a `User` in the form of the `llvm.dbg.*` intrinsic that produced it. Knowing this, I can go from `DILocalVariable` to `MetadataAsValue`, grab the users, and end up at the corresponding instruction + function. In some cases, however, LLVM will optimize the IR such that those intrinsics are...

> 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 DbgVariableIntrinsic class) > expresses everything in terms of the variables location, whereas > implicit pointers don't have a location as they represent an ext...

Hi! Is it valid to assume that the scope for a parameter-describing DILocalVariable always is a DISubprogram? Or do you know of any case where a parameter's scope can be a sub-scope of the DISubprogram? I added a check to the IR verifier and an assertion to DIBuilder::createParameterVariable() that verify this. This resulted in one test case, DebugInfo/X86/double-declare....

...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"), !DIExpression(DW_OP_plus), %c, %d) ; Salvage %d dbg.value(!DILocalVariable("x"), !DIExpression(DW_OP_plus_constu, 5, DW_OP_plus), %c, %b) ; Salvage %c needs to use DW_OP_swap dbg.value(!DILocalVariable("x"), !DIExpression(DW_OP_plus_constu, 5, DW_OP_swap, DW_...

...i8* null, i64 0, metabb !35, metabb !47), !dbg !58 call void @llvm.dbg.value(metabb i8* null, i64 0, metabb !36, metabb !47), !dbg !59 call void @llvm.dbg.value(metabb !2, i64 0, metabb !37, metabb !47), !dbg !60 >From that point on we carry dead debug info and correspondent metadata (DILocalVariable): !33 = !{!34, !35, !36, !37, ...} !34 = !DILocalVariable(name: "aa", arg: 1, scope: !28, file: !11, line: 90, type: !14) !35 = !DILocalVariable(name: "reg", arg: 2, scope: !28, file: !11, line: 90, type: !31) !36 = !DILocalVariable(name: "field", arg: 3, sc...

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 replicated by a complex expression, then the variable locat...

...smPrinter/DwarfDebug.h:130:0 #9 0x0000000002601cd4 llvm::DwarfFile::addScopeVariable(llvm::LexicalScope*, llvm::DbgVariable*) /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/llvm/lib/CodeGen/AsmPrinter/DwarfFile.cpp:104:0 #10 0x00000000025f5a29 llvm::DwarfDebug::createAbstractVariable(llvm::DILocalVariable const*, llvm::LexicalScope*) /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:746:0#11 0x00000000025f5cf4 llvm::DwarfDebug::ensureAbstractVariableIsCreatedIfScoped(std::pair<llvm::DILocalVariable const*, llvm::DILocation const*>, llvm::MDN...

...ug.h:130:0 >> #9 0x0000000002601cd4 llvm::DwarfFile::addScopeVariable(llvm::LexicalScope*, llvm::DbgVariable*) /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/llvm/lib/CodeGen/AsmPrinter/DwarfFile.cpp:104:0 >> #10 0x00000000025f5a29 llvm::DwarfDebug::createAbstractVariable(llvm::DILocalVariable const*, llvm::LexicalScope*) /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:746:0#11 0x00000000025f5cf4 llvm::DwarfDebug::ensureAbstractVariableIsCreatedIfScoped(std::pair<llvm::DILocalVariable const*, llvm::DILocation const*>, llvm::MDN...

Hey folks, Would you all mind having a bit of a design discussion around the feature both at the DWARF level and the LLVM implementation? It seems like what's currently being proposed/reviewed (based on the DWARF feature as spec'd) is a pretty big change & I'm not sure I understand the motivation, exactly. The core point of my confusion: Why does describing the thing a pointer

...void @_D7opover23barFLbZv({ i8*, i1 (i8*)* } %val_arg) #0 { %val = alloca { i8*, i1 (i8*)* }, align 8 store { i8*, i1 (i8*)* } %val_arg, { i8*, i1 (i8*)* }* %val, !dbg !18 call void @llvm.dbg.declare(metadata { i8*, i1 (i8*)* }* %val, metadata !11, metadata !19), !dbg !18 ... } !11 = !DILocalVariable(tag: DW_TAG_arg_variable, name: "val", arg: 0, scope: !6, file: !4, line: 1, type: !12) !12 = !DIBasicType(name: "bool", size: 1, align: 8, encoding: DW_ATE_boolean) The attached debug info says that val is of type bool (that's the view of the user). But it is repres...

...t !DISubprogram(name: ... !68 = distinct !DISubprogram(name: ... !69 = distinct !DISubprogram(name: "delay", scope: !14, file: !14, line: 9, type: !55, isLocal: true, isDefinition: true, scopeLine: 9, flags: DIFlagPrototyped, isOptimized: true, variables: !70) !70 = !{!71, !72} !71 = !DILocalVariable(name: "d", arg: 1, scope: !69, file: !14, line: 9, type: !11) !72 = !DILocalVariable(name: "i", scope: !69, file: !14, line: 9, type: !11) ... The IR after opt is: ; Function Attrs: nounwind define i16 @main() #0 !dbg !13 { entry: ... } !llvm.dbg.cu = !{!0} !...

...t; 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 DbgVariableIntrinsic class) > >> expresses everything in terms of the variables location, whereas > >> implicit pointers don't have...

...i8* null, i64 0, metabb !35, metabb !47), !dbg !58 call void @llvm.dbg.value(metabb i8* null, i64 0, metabb !36, metabb !47), !dbg !59 call void @llvm.dbg.value(metabb !2, i64 0, metabb !37, metabb !47), !dbg !60 >From that point on we carry dead debug info and correspondent metadata (DILocalVariable): !33 = !{!34, !35, !36, !37, ...} !34 = !DILocalVariable(name: "aa", arg: 1, scope: !28, file: !11, line: 90, type: !14) !35 = !DILocalVariable(name: "reg", arg: 2, scope: !28, file: !11, line: 90, type: !31) !36 = !DILocalVariable(name: "field", arg: 3, sc...

> On Apr 1, 2020, at 2:56 AM, Sourabh Singh Tomar <sourav0311 at gmail.com> wrote: > > > Do you mean documenting the desired frontend behavior, or adding some verifier in > LLVM? A warning for the latter is that SROA may currently emit IR that contains a > mix of declares and values for different fragments of an aggregate variable, so I > assume that is something that

>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(!DILocalVariable(x), DIExpression(DW_OP_constu, 42)) ; a constant...

...t !DISubprogram(name: ... !68 = distinct !DISubprogram(name: ... !69 = distinct !DISubprogram(name: "delay", scope: !14, file: !14, line: 9, type: !55, isLocal: true, isDefinition: true, scopeLine: 9, flags: DIFlagPrototyped, isOptimized: true, variables: !70) !70 = !{!71, !72} !71 = !DILocalVariable(name: "d", arg: 1, scope: !69, file: !14, line: 9, type: !11) !72 = !DILocalVariable(name: "i", scope: !69, file: !14, line: 9, type: !11) ... The IR after opt is: ; Function Attrs: nounwind define i16 @main() #0 !dbg !13 { entry: ... } !llvm.dbg.cu<http:...

...DW_AT_name: “character(5)” DW_AT_byte_size: 5 CHARACTER types can also have deferred length. This is supported in the new metadata as follows. !22 = !DIStringType(name: “character(*)!1”, size: 32, stringLength: !23, stringLengthExpression: !DIExpression()) !23 = !DILocalVariable(scope: !3, arg: 4, file: !4, type: !5, flags: DIFlagArtificial) This will generate the following DWARF information. DW_TAG_string_type: DW_AT_name: character(*)!1 DW_AT_string_length: 0x9b (location list) DW_AT_byte_size: 4 2.2 Fortran Array Types and Bounds In this sec...

...inct !DISubprogram(name: ... > > !69 = distinct !DISubprogram(name: "delay", scope: !14, file: !14, line: > 9, type: !55, isLocal: true, isDefinition: true, scopeLine: 9, flags: > DIFlagPrototyped, isOptimized: true, variables: !70) > > !70 = !{!71, !72} > > !71 = !DILocalVariable(name: "d", arg: 1, scope: !69, file: !14, line: 9, > type: !11) > > !72 = !DILocalVariable(name: "i", scope: !69, file: !14, line: 9, type: > !11) > > ... > > > > > The IR after opt is: > > ; Function Attrs: nounwind > > define i1...

...g a variable number of operands. It may be better however to simply replace the existing DBG_VALUE behaviour entirely instead, and 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 opera...

...inline function with two local variables. It appears that the function is already inlined before strip-dead-debug-info starts its work. As a result the DICompileUnit is cleaned and its subprograms list has no reference to the DISubprogram for the inlined function, but as there is reference from the DILocalVariables to the DISubprogram it remains (IMHO). This caused to a segmentation fault while running llc on the optimized IR file at function "constructAbstractSubprogramScopeDIE" in file DwarfDebug.cpp because the scope of the DISubprogram is null (I assume it should be the DICompileUnit). So...