search for: disubprograms

...t came to inlining that could cause two inlined functions to end up smooshed together and appear as one inlined function - but I think that was about the distinctness of the debugloc itself, not of the function). > > Hmm, maybe it's from the days when DISubprogram ownership was inverted - DISubprograms used to be owned by the DICompileUnit and the DISubprogram would refer to the llvm::Function rather than the way it is now (llvm::Function refers to DISubprogram, DISubprogram refers to DICOmpileUnit). In that old way, deduplicating a DISubprogram when IR linking would have resulted in two DICompil...

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,

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

I'm looking at cases of disagreement between assertions in the backend 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

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

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

...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 been reversed, I'm not entirely sure it's still a necessary precaution. - It broke a several uniquing cycles involving DISubprogram. The existence of the uniquing cycles meant that affe...

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

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

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

+ 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

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

...hink 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/bugs? > Now that the Function <-> DISubprogram connection has been reversed, I'm > not entirely sure it's still a necessary precaution. > > - It broke a several uniquing cycles involving...

...g to remain in the global metadata block? Oh - the DISubprogram may be referenced in other places within the global metadata so cannot move into the function metadata block. So debug metadata only reached from that DISubprogram is included in its block, but any debug metadata referenced by multiple DISubprograms would not be located within one of these blocks? The problem is that the same subprogram may be referenced from multiple functions. Consider: -- void sink(); __attribute__((always_inline)) static inline void foo() { sink(); } void caller1() { foo(); } void caller2() { foo(); } void unrelated() {}...

...se 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/bugs? > >> Now that the Function <-> DISubprogram connection has been reversed, I'm not entirely sure it's still a necessary precaution. >> >> - It broke a several uniquing...

...g to remain in the global metadata block? Oh - the DISubprogram may be referenced in other places within the global metadata so cannot move into the function metadata block. So debug metadata only reached from that DISubprogram is included in its block, but any debug metadata referenced by multiple DISubprograms would not be located within one of these blocks? > > The problem is that the same subprogram may be referenced from multiple > functions. Consider: > -- > void sink(); > __attribute__((always_inline)) static inline void foo() { sink(); } > void caller1() { foo(); } > void...

> 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

> Could you please describe what is the benefit of that? Currently there are two ways to provide DISPFlagDefinition, via bool and SPFlag, I would like to make it only via SPFlags, it will be NFC and it will make the changes in parser simpler for moving five flags from from DIFlags to DISPFlags. Currently parser checks the presence of SPFlags to see if the definition is present in bool or spflag

...lobal metadata block? Oh - the DISubprogram may be > referenced in other places within the global metadata so cannot move into > the function metadata block. So debug metadata only reached from that > DISubprogram is included in its block, but any debug metadata referenced by > multiple DISubprograms would not be located within one of these blocks? > > The problem is that the same subprogram may be referenced from multiple > functions. Consider: > -- > void sink(); > __attribute__((always_inline)) static inline void foo() { sink(); } > void caller1() { foo(); } > void c...

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