similar to: [LLVMdev] RFC: Metadata attachments to function definitions

> On 2015 Apr 15, at 10:06, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Tue, Apr 14, 2015 at 10:59 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > > On 2015 Apr 14, at 21:46, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Tue, Apr 14, 2015 at 9:33 PM, Duncan P. N. Exon Smith > > <dexonsmith at

> On 2015-Apr-15, at 08:59, Reid Kleckner <rnk at google.com> wrote: > > Conventional wisdom, which is often wrong, says that bytes in Function are precious. In the past we've bent over backwards to put bits on Function and have DenseMaps in LLVMContexts and Modules. I think this is probably the *wrong* approach for debug info, which, when it's being used, is used

> Date: Tue, 14 Apr 2015 21:33:03 -0700 > From: "Duncan P. N. Exon Smith" <dexonsmith at apple.com> > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Subject: [LLVMdev] RFC: Metadata attachments to function definitions > Message-ID: <BF4002F0-06DC-4A25-AF84-7D21AD48121A at apple.com> > Content-Type: text/plain; charset=us-ascii > >

In r219010, I merged integer and string fields into a single header field. By reducing the number of metadata operands used in debug info, this saved 2.2GB on an `llvm-lto` bootstrap. I've done some profiling of DW_TAGs to see what parts of PR17891 and PR17892 to tackle next, and I've concluded that they will be insufficient. Instead, I'd like to implement a more aggressive plan,

> 3. Any comments on the patch itself? > > The one major thing to be aware of is that it isn't safe to use &V[0] when V > is an empty std::vector Oh dear. That's a bit of a flaw in the plan. I suppose the solution is to switch to SmallVector whenever this might be a problem. I'm a bit concerned that any new &empty[0] problems that are introduced will go unnoticed.

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

On Wed, Oct 15, 2014 at 8:53 PM, Alex Rosenberg <alexr at leftfield.org> wrote: > As all of these transforms are 1-to-1, can we still support the older metadata and convert it on the fly? > I'd prefer not to keep all of that code around to interpret both versions without a very good reason. -eric > Alex > >> On Oct 13, 2014, at 3:02 PM, Duncan P. N. Exon Smith

I'm getting close to executing the transition to the new debug info hierarchy. For reference, I've attached two WIP patches (which would be squashed before commit) and the WIP upgrade script I'm using. - transition-code.patch: Change the `DIDescriptor` hierarchy to lightweight wrappers around the subclasses of `DebugNode` (instead of rather heavier wrappers around

On Friday 15 May 2009 05:50, Jay Foad wrote: > > 3. Any comments on the patch itself? > > > > The one major thing to be aware of is that it isn't safe to use &V[0] > > when V is an empty std::vector > > Oh dear. That's a bit of a flaw in the plan. I suppose the solution is > to switch to SmallVector whenever this might be a problem. Or use iterators.

On Mon, Oct 13, 2014 at 7:01 PM, Eric Christopher <echristo at gmail.com> wrote: > On Mon, Oct 13, 2014 at 6:59 PM, Sean Silva <chisophugis at gmail.com> wrote: > > For those interested, I've attached some pie charts based on Duncan's > data > > in one of the other posts; successive slides break down the usage > > increasingly finely. To my

On Oct 27, 2011, at 10:39 PM, Talin wrote: > 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.) >> >>

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 DIBuilder::finalize(). I even put a debug print statement right after it, so that I could be sure that the

Hi all, We have profiled [1] the memory usage in LLVM when LTO'ing Chromium, and we've found that one of the top consumers of memory is the DWARF emitter in lib/CodeGen/AsmPrinter/Dwarf*. I've been reading the DWARF emitter code and I have a few ideas in mind for how to reduce its memory consumption. One idea I've had is to restructure the emitter so that (for the most part) it

For those interested, I've attached some pie charts based on Duncan's data in one of the other posts; successive slides break down the usage increasingly finely. To my understanding, they represent the number of Value's (and subclasses) allocated. On Mon, Oct 13, 2014 at 3:02 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > In r219010, I merged integer and

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 DIBuilder::finalize(). I even put a debug print statement right after it, so that I could be sure that the code was being executed. I also insured that it was getting

On Oct 5, 2010, at 11:23 PM, Nick Lewycky wrote: >> >> Here is another version of the patch. This one includes also a small patch to llvm-gcc so that it generates the type metadata for structures and classes. This one also generates and parses correctly the metadata for .ll files. No .bc support yet. The biggest problem with this version is that it breaks when the compiler/linker

>>> Here is another version of the patch. This one includes also a small patch to llvm-gcc so that it generates the type metadata for structures and classes. This one also generates and parses correctly the metadata for .ll files. No .bc support yet. The biggest problem with this version is that it breaks when the compiler/linker performs type reductions, and I don't understand

(sorry for the duplicate Fred, I failed at reply-all the first time) On Wed, Oct 22, 2014 at 6:33 PM, Frédéric Riss <friss at apple.com> wrote: > > > On Oct 22, 2014, at 4:57 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > Just working on some of the gmlt+fission debug info stuff and I came > across a comment that might be relevant to reducing the

> On Feb 20, 2015, at 9:00 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Feb 19, 2015 at 7:49 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com <mailto:dexonsmith at apple.com>> wrote: > I'm getting close to executing the transition to the new debug info > hierarchy. For reference, I've attached two WIP patches (which would

On 2009-05-15, at 07:26, David Greene wrote: > On Friday 15 May 2009 05:50, Jay Foad wrote: >> > >>> The one major thing to be aware of is that it isn't safe to use >>> &V[0] when V is an empty std::vector >> >> Oh dear. That's a bit of a flaw in the plan. I suppose the solution >> is to switch to SmallVector whenever this might be a