[llvm-dev] StripDeadDebugInfo for static inline functions.

Arsen Hakobyan via llvm-dev llvm-dev at lists.llvm.org
Sun Jan 14 08:33:26 PST 2018


Thanks Paul,
Hi Adrian and David I would really appreciate any comments, thoughts
assumptions.

If additional information is needed please let me know.

Regards,
Arsen

On Sat, Jan 13, 2018 at 2:54 AM, Robinson, Paul <paul.robinson at sony.com>
wrote:

> Hi Arsen, we are beyond what I understand about how metadata operates.
> Maybe Adrian or David knows.
>
> --paulr
>
>
>
> *From:* Arsen Hakobyan [mailto:hakobyan.ars at gmail.com]
> *Sent:* Friday, January 12, 2018 12:16 PM
> *To:* Robinson, Paul
> *Cc:* llvm-dev at lists.llvm.org; David Blaikie
> *Subject:* Re: [llvm-dev] StripDeadDebugInfo for static inline functions.
>
>
>
> Just one update:
>
>
>
> the function causing the segmentation fault is the following:
>
>
>
>  359 void DwarfDebug::constructAbstractSubprogramScopeDIE(LexicalScope
> *Scope) {
>
>  360   assert(Scope && Scope->getScopeNode());
>
>  361   assert(Scope->isAbstractScope());
>
>  362   assert(!Scope->getInlinedAt());
>
>  363
>
>  364   const MDNode *SP = Scope->getScopeNode();
>
>  365
>
>  366   ProcessedSPNodes.insert(SP);
>
>  367
>
>  368   // Find the subprogram's DwarfCompileUnit in the SPMap in case the
> subprogram
>
>  369   // was inlined from another compile unit.
>
>  370   auto &CU = SPMap[SP];
>
>  371   forBothCUs(*CU, [&](DwarfCompileUnit &CU) {
>
>  372     CU.constructAbstractSubprogramScopeDIE(Scope);
>
>  373   });
>
>  374 }
>
>
>
>
>
> Here I checked that "SPMap.lookup(Scope->getScopeNode());" returns null.
> If the transformation does right things then probably there is other issue
> and SPMap[SP] for inlined function should find the main CompileUnit
> anyway.  What do you think about this?
>
>
>
> Regards,
>
> Arsen
>
>
>
> On Sat, Jan 13, 2018 at 12:11 AM, Arsen Hakobyan <hakobyan.ars at gmail.com>
> wrote:
>
> Hi Paul,
>
>
>
> Thanks for your response.
>
> Let me actually post more details visualizing my case. Assuming that can
> help.
>
>
>
> so the IR before the opt tool is running is:
>
>
>
> ; Function Attrs: nounwind
>
> define i16 @main() #0 !dbg !13 {
>
> entry:
>
>   %retval = alloca i16, align 1
>
>     ...
>
> }
>
>
>
> ; Function Attrs: inlinehint nounwind
>
> define internal void @delay(i16 %d) #4 !dbg !69 {
>
> entry:
>
>   %d.addr = alloca i16, align 1
>
>   %i = alloca i16, align 1
>
>   ...
>
> }
>
>
>
> !llvm.dbg.cu = !{!0}
>
> !llvm.module.flags = !{!84, !85}
>
> !llvm.ident = !{!86}
>
>
>
> !0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer:
> "clang version 3.8.0 Revision 72230", isOptimized: true, runtimeVersion: 0,
> emissionKind: 1, enums: !2, retainedTypes: !3, subprograms: !12, globals:
> !73)
>
> ...
>
> !12 = !{!13, !54, !57, !60, !61, !62, !65, !66, !67, !68, !69}
>
> !13 = distinct !DISubprogram(name: "main", scope: !14, file: !14, line:
> 15, type: !15, isLocal: false, isDefinition: true, scopeLine: 15,
> isOptimized: true, variables: !17)
>
> ...
>
> !54 = distinct !DISubprogram(name: ...
>
> !57 = distinct !DISubprogram(name: ...
>
> !60 = distinct !DISubprogram(name: ...
>
> !61 = distinct !DISubprogram(name: ...
>
> !62 = distinct !DISubprogram(name: ...
>
> !65 = distinct !DISubprogram(name: ...
>
> !66 = distinct !DISubprogram(name: ...
>
> !67 = distinct !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}
>
> !llvm.module.flags = !{!64, !65}
>
> !llvm.ident = !{!66}
>
>
>
> !0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer:
> "clang version 3.8.0 Revision 72230", isOptimized: true, runtimeVersion: 0,
> emissionKind: 1, enums: !2, retainedTypes: !3, subprograms: !12, globals:
> !54)
>
> ...
>
> !12 = !{!13}
>
> !13 = distinct !DISubprogram(name: "main", scope: !14, file: !14, line:
> 15, type: !15, isLocal: false, isDefinition: true, scopeLine: 15,
> isOptimized: true, variables: !17)
>
> !14 = !DIFile(filename: "main.c", directory: "path_to_directory")
>
> ...
>
> !68 = !DILocalVariable(name: "d", arg: 1, scope: !69, file: !14, line: 9,
> type: !11)
>
> !69 = distinct !DISubprogram(name: "delay", scope: !14, file: !14, line:
> 9, type: !70, isLocal: true, isDefinition: true, scopeLine: 9, flags:
> DIFlagPrototyped, isOptimized: true, variables: !72)
>
> ...
>
> !73 = !DILocalVariable(name: "i", scope: !69, file: !14, line: 9, type:
> !11)
>
> ...
>
>
>
>
>
> I checked the StripSymbol.cpp file and there is no difference between
> version I am using (from clang 3.8) and current (6.0.0) version.
>
>
>
> As you can see the !12 node does not contain reference to !69 after
> optimizations which I think is incorrect. I assume that !69 has not been
> removed because there are two nodes (!68 and !73) referenced to it as the
> scope. But that should force the transformations to not remove the link
> from !12. Is it right?
>
>
>
> Thank you very much.
>
> Arsen
>
>
>
>
>
> On Fri, Jan 12, 2018 at 10:21 PM, Robinson, Paul <paul.robinson at sony.com>
> wrote:
>
> I'm not as familiar with all the ins and outs of metadata as maybe I
> should be, but ultimately the inlined function should have a DWARF
> description contained within the description of the caller (which is why
> you're seeing the call to constructAbstractSubprogramScopeDIE).  That
> suggests that the DISubprogram for the inlined function ought to remain,
> and its scope should be the DICompileUnit.
>
> --paulr
>
>
>
> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *Arsen
> Hakobyan via llvm-dev
> *Sent:* Friday, January 12, 2018 1:57 AM
> *To:* llvm-dev at lists.llvm.org
> *Subject:* [llvm-dev] StripDeadDebugInfo for static inline functions.
>
>
>
> Hi all,
>
>
>
> I would like to understand the strip-dead-debug-info transformation.
>
> In my test case there is a static 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 I would like to know what would be the correct solution for this issue:
> Update optimization to not remove reference from the subprograms list, or
> to skip finding scope in llc.
>
>
>
> Any help is highly appreciated.
>
>
>
> Thanks,
>
> Arsen
>
>
>
>
>
> --
>
>
>
> If it's not fun you're not doing it right -- Fran Tarkenton
>
>
>
>
>
> --
>
>
>
> If it's not fun you're not doing it right -- Fran Tarkenton
>
>
>
>
>
> --
>
>
>
> If it's not fun you're not doing it right -- Fran Tarkenton
>



-- 

If it's not fun you're not doing it right -- Fran Tarkenton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180114/4f9da46c/attachment.html>


More information about the llvm-dev mailing list