search for: disubprogram

I saw https://reviews.llvm.org/rGe17f52d623cc146b7d9bf5a2e02965043508b4c4#949392 "Add a verifier check that rejects non-distinct DISubprogram function" (which has currently be reverted) today which made me wonder why a DISubprogram needs to be distinct? David told me the following and encouraged me to ask in the upstream: > May be historical at this point, I'm not quite sure. (I remember there being some complicated issues...

...eUnit(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 !DIS...

...ast and don't anymore - what's the rule about backwards compatibility here, then? It seems like any time we regenerate a bitcode compat test that's questionable because it means we won't be compatible with that bitcode we said we should be compatible with? > We have two kinds of DISubprograms: > - uniqued DISubprograms are part of the type system and describe function *types*. They don't have a unit: field, because they want to be uniqued across compile units. > - distinct DISubprograms describe one specific function definition. They belong to a compile unit and thus have a u...

...and what the Verifier checks for (for http://reviews.llvm.org/D16083). One of these seems to be the question of whether a DISuprogram may exist without a DICompileUnit. Currently the Verifier doesn't care, but there are a few assertions to this extent in the backend. Possible options are: 1) A DISubprogram may exist without a DICompileUnit (what would we have to change in the backend?) 2) A DISubprogram's scope may be null, but only if there's a DICompileUnit that references it. 3) A DISubprogram's scope may not be null, but the referenced DICompileUnit need not necessarily contain it 4)...

...eUnit(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 !DIS...

...ducer: > "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 = distinc...

A few disjoint thoughts; sorry they're so delayed (I skimmed the responses below, and I think these are still relevant/not covered elsewhere). Firstly, why *should* DISubprogram definitions be distinct? There were two reasons this was valuable (this was from before there was a cu: link). - It helped to fix long-standing bugs in the IRLinker, where uniqued-DISubprograms in different compile units would coalesce. Now that the Function <-> DISubprogram connection has...

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

...ducer: > "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 = distinc...

...;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] StripDeadDebugI...

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

Branching off from a discussion of improvements to DIGlobalVariable representations that Adrian's working on - got me thinking about related changes that have already been made to DISubprogram. To reduce duplicate debug info when things like linkonce_odr functions were deduplicated in LTO linking, the relationship between a CU and DISubprogram was inverted (instead of a CU maintaining a list of subprograms, subprograms specify which CU they come from - and the llvm::Function references...

On Fri, Dec 23, 2016 at 11:47 AM Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > A few disjoint thoughts; sorry they're so delayed (I skimmed the responses > below, and I think these are still relevant/not covered elsewhere). > > Firstly, why *should* DISubprogram definitions be distinct? There were > two reasons this was valuable (this was from before there was a cu: link). > > - It helped to fix long-standing bugs in the IRLinker, where > uniqued-DISubprograms in different compile units would coalesce. > Any idea why that ^ was a problem/b...

...inking? > > > c) Emitting unnecessary `DI*` instances (that aren't relevant to code). > > Here is my recollection of some peak memory stats on a small testcase > during thin-LTO, which should be a decent indicator of (b): > > - ~150MB: DILocation > - ~100MB: DISubprogram > - ~70MB: DILocalVariable > - ~50MB: (cumulative) DIType descendents > > It looks, suprisingly, like types are not the primary bottleneck. > > There are caveats: > > - `DISubprogram` declarations -- member function descriptors -- are > part of the type hiera...

...t;> On Fri, Dec 23, 2016 at 11:47 AM Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> A few disjoint thoughts; sorry they're so delayed (I skimmed the responses below, and I think these are still relevant/not covered elsewhere). >> >> Firstly, why *should* DISubprogram definitions be distinct? There were two reasons this was valuable (this was from before there was a cu: link). >> >> - It helped to fix long-standing bugs in the IRLinker, where uniqued-DISubprograms in different compile units would coalesce. > > Any idea why that ^ was a probl...

...) Emitting unnecessary `DI*` instances (that aren't relevant to code). > > > > Here is my recollection of some peak memory stats on a small testcase > > during thin-LTO, which should be a decent indicator of (b): > > > > - ~150MB: DILocation > > - ~100MB: DISubprogram > > - ~70MB: DILocalVariable > > - ~50MB: (cumulative) DIType descendents > > > > It looks, suprisingly, like types are not the primary bottleneck. > > > > There are caveats: > > > > - `DISubprogram` declarations -- member function descriptors -...

> On 2016-Jan-15, at 06:46, Keno Fischer <kfischer at college.harvard.edu> wrote: > > Looking at this again, I think I was under the mistaken impression that the DISubprogram's scope would have to be the compile unit, but it seems we also currently allow it to be a DIFile (or any other kind of scope). In that case, I suppose the behavior that the backend expects is that every DISubprogram is referenced from some DICompileUnit contained in llvm.dbg.cu. I'll imple...

...olean, as in example spFlags: DISPFlagThunk, isLocal: True. - Chirag. -----Original Message----- From: Djordje Todorovic <djordje.todorovic at rt-rk.com> Sent: 20 February 2020 14:40 To: Chirag Patel <Chirag at raincode.com>; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] [LLVM][DISubprogram][LL format updation query] Question regarding moving DISubprogram DIFlags to DISPFlag. Hi Chirag, On 20.2.20. 09:57, Chirag Patel wrote: > Yes, removing the support for isLocal, isDefinition fields completely from ll files, currently the LLParser still parses it. I want to remove it and update...

...) Emitting unnecessary `DI*` instances (that aren't relevant to code). > > > > Here is my recollection of some peak memory stats on a small testcase > > during thin-LTO, which should be a decent indicator of (b): > > > > - ~150MB: DILocation > > - ~100MB: DISubprogram > > - ~70MB: DILocalVariable > > - ~50MB: (cumulative) DIType descendents > > > > It looks, suprisingly, like types are not the primary bottleneck. > > > > There are caveats: > > > > - `DISubprogram` declarations -- member function descriptors -...

I just wrote an IR Verifier check that catches the following situation: ; RUN: not llvm-as %s -disable-output 2>&1 | FileCheck %s define void @f1() !dbg !4 { unreachable } ; CHECK: DISubprogram attached to more than one function define void @f2() !dbg !4 { unreachable } !llvm.dbg.cu = !{!1} !1 = distinct !DICompileUnit(language: DW_LANG_C99, file: !2) !2 = !DIFile(filename: "t.c", directory: "/path/to/dir") !3 = !{} !4 = distinct !DISubprogram(name:...