[llvm-dev] StripDeadDebugInfo for static inline functions.
Arsen Hakobyan via llvm-dev
llvm-dev at lists.llvm.org
Mon Jan 15 13:20:41 PST 2018
Hi Jonas,
Thank you very much for your response. It seems that the changes you
pointed is the fix for the issue I have.
I am not able to test that revision but I found a workaround using the
logic of the fix.
Regards,
Arsen
On Mon, Jan 15, 2018 at 4:04 PM, Jonas Devlieghere <jdevlieghere at apple.com>
wrote:
> + Adrian
> + David
>
> Hi Arsen,
>
> This sounds like a bug to me. Have you tried reproducing it on trunk? For
> instance, I see that the relation between DICompileUnit and DISubprogram
> was changed in the meantime (https://reviews.llvm.org/D19034).
>
> If this no longer occurs on master you could bisect the compiler to find
> the commit(s) that fix this and consider backporting them locally. If not,
> you should file a bug on bugs.llvm.org and attach the source and commands
> you’re running. I’d be happy to take a look at it.
>
> Jonas
>
>
> On 14 Jan 2018, at 16:33, Arsen Hakobyan via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
--
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/20180116/563fe3e4/attachment-0001.html>
More information about the llvm-dev
mailing list