similar to: [LLVMdev] How to strip all unused debugging metadata?

On 24 April 2012 16:04, Matt Pharr <matt.pharr at gmail.com> wrote: > When I generate debug information for a source file that has a number of static functions that are unused, all of the debugging metadata that I generated for them during initial compilation remains even after the source function definitions have been stripped out of the IR.  (e.g. in the MD for DW_TAG_compile_unit's

On Apr 24, 2012, at 5:36 AM, Renato Golin wrote: > On 24 April 2012 16:04, Matt Pharr <matt.pharr at gmail.com> wrote: >> When I generate debug information for a source file that has a number of static functions that are unused, all of the debugging metadata that I generated for them during initial compilation remains even after the source function definitions have been stripped

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

On Thu, Dec 15, 2016 at 11:35 AM Mehdi Amini <mehdi.amini at apple.com> wrote: > > > 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

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

On Thu, Dec 15, 2016 at 11:26 AM Teresa Johnson <tejohnson at google.com> wrote: > Trying to wrap my brain around this, so a few questions below. =) > Sure thing - sorry, did assume a bit too much arcane context here. > > On Thu, Dec 15, 2016 at 10:54 AM, David Blaikie <dblaikie at gmail.com> > wrote: > > Branching off from a discussion of improvements to

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 Thu, Dec 15, 2016 at 11:38 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Thu, Dec 15, 2016 at 11:26 AM Teresa Johnson <tejohnson at google.com> > wrote: > >> Trying to wrap my brain around this, so a few questions below. =) >> > > Sure thing - sorry, did assume a bit too much arcane context here. > > >> >> On Thu, Dec

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

> 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 Thu, Dec 15, 2016 at 1:30 PM Teresa Johnson <tejohnson at google.com> wrote: On Thu, Dec 15, 2016 at 11:38 AM, David Blaikie <dblaikie at gmail.com> wrote: On Thu, Dec 15, 2016 at 11:26 AM Teresa Johnson <tejohnson at google.com> wrote: Trying to wrap my brain around this, so a few questions below. =) Sure thing - sorry, did assume a bit too much arcane context here.

On Thu, Dec 15, 2016 at 2:08 PM, David Blaikie <dblaikie at gmail.com> wrote: > On Thu, Dec 15, 2016 at 1:30 PM Teresa Johnson <tejohnson at google.com> > wrote: > > On Thu, Dec 15, 2016 at 11:38 AM, David Blaikie <dblaikie at gmail.com> > wrote: > > > > On Thu, Dec 15, 2016 at 11:26 AM Teresa Johnson <tejohnson at google.com> > wrote: >

On Thu, Dec 15, 2016 at 4:17 PM Teresa Johnson <tejohnson at google.com> wrote: > On Thu, Dec 15, 2016 at 2:08 PM, David Blaikie <dblaikie at gmail.com> wrote: > > On Thu, Dec 15, 2016 at 1:30 PM Teresa Johnson <tejohnson at google.com> > wrote: > > On Thu, Dec 15, 2016 at 11:38 AM, David Blaikie <dblaikie at gmail.com> > wrote: > > > > On

On Thu, Dec 15, 2016 at 4:20 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Thu, Dec 15, 2016 at 4:17 PM Teresa Johnson <tejohnson at google.com> > wrote: > >> On Thu, Dec 15, 2016 at 2:08 PM, David Blaikie <dblaikie at gmail.com> >> wrote: >> >> On Thu, Dec 15, 2016 at 1:30 PM Teresa Johnson <tejohnson at google.com>

Thanks Eric. I know some of the references are in the code used for backward compatibility. - Devang On Feb 13, 2012, at 9:21 AM, Eric Christopher <echristo at apple.com> wrote: > Thanks. I'll get them. :) > > -eric > > On Feb 13, 2012, at 1:41 AM, Bendersky, Eli wrote: > >> Thanks. Note that there are still a few references to this MDNode scattered throughout

On Mon, Oct 24, 2011 at 9:17 AM, Devang Patel <dpatel at apple.com> wrote: > > On Oct 23, 2011, at 12:03 AM, Talin wrote: > > Just a follow up on this - I am still having problems, I never did figure > out a solution. (I've been running with debug off for the last month so that > I could get work done.) > > Here's what I am seeing: I am definitely calling

That happens because we create the subprogram below as a context to the “DW_TAG_typedef” that was created as a type to “DW_TAG_pointer_type” that was added to the retained type list because of the explicit cast to (T*). This is the code that creates DW_TAG_subprogram: DIE *DwarfUnit::getOrCreateSubprogramDIE(const DISubprogram *SP, bool Minimal) { ... // DW_TAG_inlined_subroutine may refer

Eric, Devang, FYI exactly the same applies for llvm.dbg.gv - it's also still listed in the docs and in various places throughout the code, although no longer generated. Eli From: Devang Patel [mailto:dpatel at apple.com] Sent: Monday, February 13, 2012 19:26 To: Eric Christopher Cc: Bendersky, Eli; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] generating !llvm.dbg.sp Thanks Eric. I know

I've opened PR 12050 to track the problem with llvm.dbg.gv Eli From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Bendersky, Eli Sent: Tuesday, February 14, 2012 13:45 To: Devang Patel; Eric Christopher Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] generating !llvm.dbg.sp Eric, Devang, FYI exactly the same applies for llvm.dbg.gv - it's also