similar to: Should DISubprogram's scope be allowed to be null?

> 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

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

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,

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

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

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

+ 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

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

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

On Fri, Sep 25, 2020 at 4:08 PM Adrian Prantl <aprantl at apple.com> wrote: > > First — thanks for fixing the test for me! I'm a bit curious about the test - any idea how it came to be, if it's invalid? Did we produce such bitcode in the past and don't anymore - what's the rule about backwards compatibility here, then? It seems like any time we regenerate a bitcode

On Tue, Mar 22, 2016 at 7:28 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > I have some ideas to allow the BitcodeReader to lazy-load debug info > metadata, and wanted to air this on llvm-dev before getting too deep > into the code. > > Motivation > ========== > > Based on some analysis Mehdi ran (ping him for details), there are three > (related)

> On 2016-Mar-23, at 07:17, Teresa Johnson <tejohnson at google.com> wrote: > > > > On Tue, Mar 22, 2016 at 7:28 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > I have some ideas to allow the BitcodeReader to lazy-load debug info > metadata, and wanted to air this on llvm-dev before getting too deep > into the code. > > Motivation >

On Wed, Mar 23, 2016 at 9:31 AM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2016-Mar-23, at 07:17, Teresa Johnson <tejohnson at google.com> wrote: > > > > > > > > On Tue, Mar 22, 2016 at 7:28 PM, Duncan P. N. Exon Smith < > dexonsmith at apple.com> wrote: > > I have some ideas to allow the BitcodeReader to

> On 2016-Mar-23, at 09:42, Teresa Johnson <tejohnson at google.com> wrote: > > > > On Wed, Mar 23, 2016 at 9:31 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > > On 2016-Mar-23, at 07:17, Teresa Johnson <tejohnson at google.com> wrote: > > > > > > > > On Tue, Mar 22, 2016 at 7:28 PM, Duncan P. N. Exon Smith

Here are some issues that I am unclear about. What would be great is if the answers could be incorporated into the comments and documentation for DIFactory and DebugInfo.h: 1) What types of DIScope are valid arguments for DebugLoc::get()? The method takes an MDNode* argument, so looking at the function signature is no help. For example, DIFile is a subtype of DIScope, however looking at

I was just going to say: With well-formed debug info it should create a deep copy up until the DISubprogram, but no further. But because the DISubprogram linked to the Function is missing the special handling of the DISubprogram (that would prohibit cloning the DICompileUnit is side-stepped). But then I remembered the discussion we had in

On Fri, Jan 15, 2016 at 11:24 AM, David Blaikie <dblaikie at gmail.com> wrote: > Diego: To include line/col info for backend diagnostics, we produced debug > info but omitted the llvm.dbg.cu entry, right? So there are subprogram > debug info descriptions that are not referenced from a CU in llvm.dbg.cu, > yes? > Yes, that and for sample PGO. Omitting llvm.dbg.cu prevents

+pcc, who had some other ideas/patch out for improving memory usage of debug info +Reid, who's responsible for the windows/CodeView/PDB debug info which is motivating some of the ideas about changes to type emission So how does this relate, or not, to Peter's (pcc) work trying to reduce the DIE overhead during code gen? Are you folks chasing different memory bottlenecks? Are they both

- old Keno +current Keno > On Jun 19, 2017, at 2:59 PM, Adrian Prantl <aprantl at apple.com> wrote: > > In your example the instructions in the cloned function have debug locations belonging to a different function, and the function itself is missing a DISubprogram metadata attachment. > >> (lldb) p OldFunc->dump() >> >> ; Function Attrs: nounwind optsize