thr3ads.net - llvm dev - [llvm-dev] StripDeadDebugInfo for static inline functions. [Jan 2018]

If this information is useful, please help other people find it:
Share via:

Robinson, Paul via llvm-dev

2018-Jan-12 22:54 UTC

[llvm-dev] StripDeadDebugInfo for static inline functions.

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<mailto: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<http://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<http://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<mailto: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<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<mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180112/60d8fc92/attachment.html>

Arsen Hakobyan via llvm-dev

2018-Jan-14 16:33 UTC

head link

[llvm-dev] StripDeadDebugInfo for static inline functions.

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>

Jonas Devlieghere via llvm-dev

2018-Jan-15 12:04 UTC

head link

[llvm-dev] StripDeadDebugInfo for static inline functions.

+ 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
<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 <http://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 <mailto: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
<mailto:hakobyan.ars at gmail.com>]
> Sent: Friday, January 12, 2018 12:16 PM
> To: Robinson, Paul
> Cc: llvm-dev at lists.llvm.org <mailto: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 <mailto: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 <http://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 <http://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 <mailto: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
<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 <mailto: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 <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180115/c1e7e35b/attachment.html>

Possibly Parallel Threads

Search for more maybe matching threads

llvm dev - Jan 2018 - StripDeadDebugInfo for static inline functions.

[llvm-dev] StripDeadDebugInfo for static inline functions.

[llvm-dev] StripDeadDebugInfo for static inline functions.

[llvm-dev] StripDeadDebugInfo for static inline functions.

Possibly Parallel Threads