similar to: Canonical representation for empty lists in debug info metadata

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,

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

On Fri, Apr 15, 2016 at 2:27 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2016-Apr-15, at 10:27, David Blaikie <dblaikie at gmail.com> wrote: > > > > > > > > On Fri, Apr 15, 2016 at 9:50 AM, Duncan P. N. Exon Smith < > dexonsmith at apple.com> wrote: > > Since I haven't heard any objections to the direction,

On Fri, Apr 15, 2016 at 9:50 AM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > Since I haven't heard any objections to the direction, I'm planning to > commit this (step 4) when I find some cycles; likely over the weekend. > > To make this more concrete (in case someone is silently concerned) I've > posted my WIP patches below. They apply cleanly to

> On 2016-Mar-22, at 20:11, Eric Christopher <echristo at gmail.com> wrote: > >> On Tue, Mar 22, 2016 at 8:04 PM David Blaikie <dblaikie at gmail.com> wrote: >> +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

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 have no objections to any of this FWIW :) -eric On Tue, Mar 29, 2016 at 6:46 PM Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2016-Mar-22, at 20:11, Eric Christopher <echristo at gmail.com> wrote: > > > >> On Tue, Mar 22, 2016 at 8:04 PM David Blaikie <dblaikie at gmail.com> > wrote: > >> +pcc, who had some other

On Fri, Apr 15, 2016 at 4:04 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2016-Apr-15, at 14:53, David Blaikie <dblaikie at gmail.com> wrote: > > > > > > > >> On Fri, Apr 15, 2016 at 2:27 PM, Duncan P. N. Exon Smith < > dexonsmith at apple.com> wrote: > >> > >> > On 2016-Apr-15, at 10:27, David

+ 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

On Tue, Mar 22, 2016 at 8:04 PM David Blaikie <dblaikie at gmail.com> wrote: > +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 I discussed this with Adrian and Mehdi at the social last

On Mon, Jul 30, 2018 at 6:52 AM <paul.robinson at sony.com> wrote: > > > > > -----Original Message----- > > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Xin > > Tong via llvm-dev > > Sent: Friday, July 27, 2018 9:33 PM > > To: llvm-dev > > Subject: [llvm-dev] ThinLTO Bug ? > > > > Hi > > > > I

Hi I have encountered a module verification failure when running 2 files with thin-lto (I hit this bug in the link step in LTO on a really large program and I reduced to this test case). ~/llvmfb/build-debug/bin/llvm-lto2 run -o c a.o b.o -r a.o,c,px -r b.o,a,px -r b.o,b,px -r a.o,gv -r b.o,gv Called function is not the same type as the call! %2 = call i1 bitcast (i1 (%struct.TA*)* @b to i1

+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

Way back in r107027, we started preserving type information of local variables of functions that are optimized away. This seemed strange to me so I dug into the history: apparently, this is so that ctfconvert can find these types (so they can be exposed in dtrace). E.g., this commit made it so that for this C code: static void foo(void) { struct X { int b; } v; } we always get the type

> On Mar 22, 2016, at 8:04 PM, David Blaikie <dblaikie at gmail.com> wrote: > > +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

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) compile-time bottlenecks we're seeing with `-flto=thin -g`: a) Reading the large number of Metadata bitcode records in the global

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

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 Tue, Mar 22, 2016 at 9:48 PM, Duncan Exon Smith <dexonsmith at apple.com> wrote: > > On Mar 22, 2016, at 8:04 PM, David Blaikie <dblaikie at gmail.com> wrote: > > +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