similar to: Why does a DISubprogram need to be distinct?

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 Dec 23, 2016, at 18:36, David Blaikie <dblaikie at gmail.com> wrote: > > > >> 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

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

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

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

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

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

> >> On 2016-Apr-15, at 17:12, David Blaikie <dblaikie at gmail.com> wrote: >> >> >> >> 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

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

> On Dec 15, 2016, at 10:54 AM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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

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

+ 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

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,

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

Trying to wrap my brain around this, so a few questions below. =) On Thu, Dec 15, 2016 at 10:54 AM, David Blaikie <dblaikie at gmail.com> wrote: > 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

+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