similar to: [LLVMdev] Debug info: type uniquing for C++ and the status on building clang with "-flto -g"

On Tue, Nov 12, 2013 at 1:01 PM, David Blaikie <dblaikie at gmail.com> wrote: > Hi Manman, > > Thanks for sending this summary and progress plans - it's great to see the > impact your changes have had and ideas for future direction. > > Type uniquing for C++ is in. Some data for Xalan with -flto -g: >> 9.9MB raw dwarf size, peak memory usage at 2.8GB >> The

Hi Manman, Thanks for sending this summary and progress plans - it's great to see the impact your changes have had and ideas for future direction. Type uniquing for C++ is in. Some data for Xalan with -flto -g: > 9.9MB raw dwarf size, peak memory usage at 2.8GB > The raw dwarf size was 58MB, memory usage was 7GB back in May, 2013. > Other efforts at size reduction helped, and type

On Tue, Nov 12, 2013 at 2:08 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Tue, Nov 12, 2013 at 1:01 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> Hi Manman, >> >> Thanks for sending this summary and progress plans - it's great to see >> the impact your changes have had and ideas for future direction. >> >>

-llvm-commits, +llvmdev > On Oct 2, 2014, at 2:57 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > Author: dexonsmith > Date: Thu Oct 2 16:56:57 2014 > New Revision: 218914 > > URL: http://llvm.org/viewvc/llvm-project?rev=218914&view=rev > Log: > DI: Fold constant arguments into a single MDString > > This patch addresses the first

On 20 June 2013 17:51, Manman Ren <mren at apple.com> wrote: > > The intent of this proposal is to speedup compilation of "-flto -g" for c++ programs. > This is based on discussions with Adrian, David and Eric. > > --------------------------- > Problem: > A single class can be used in multiple source files and the DI (Debug Info) class is included in multiple

Wouldn't it be simpler to name the metadata based on the hash of the content? Then you could use a normal reference to that metadata without needing to create a new type or teach the rest of llvm how to use it... On Fri, Jun 21, 2013 at 3:22 PM, Manman Ren <mren at apple.com> wrote: > > A summary of options for issue #3: > 3> To actually access the MDNode referenced via

More details please :] What do you mean by "name the metadata"? Are you referring to the name field of the MDNode? Thanks, Manman On Jun 21, 2013, at 7:19 AM, David Blaikie wrote: > > On Jun 21, 2013 1:19 AM, "Jeremy Lakeman" <Jeremy.Lakeman at gmail.com> wrote: > > > > Wouldn't it be simpler to name the metadata based on the hash of the content?

On Thu, Jun 20, 2013 at 5:25 PM, Manman Ren <mren at apple.com> wrote: > > On Jun 20, 2013, at 5:18 PM, David Blaikie <dblaikie at gmail.com> wrote: > > On Thu, Jun 20, 2013 at 5:13 PM, Manman Ren <mren at apple.com> wrote: > > > On Jun 20, 2013, at 4:52 PM, David Blaikie wrote: > > On Thu, Jun 20, 2013 at 4:45 PM, Manman Ren <mren at apple.com>

A summary of options for issue #3: 3> To actually access the MDNode referenced via the hash value, we need to perform a lookup from the hash value to find the corresponding MDNode. The questions are where to store this map and how to keep it up-to-date when a MDNode is replaced. --------------------- Option a) a map in DwarfDebug, AsmWriter and DIBuilder, modify access functions in DI classes

Hi All, In LTO, we load in the source modules and link the source modules into a destination module. Lots of MDNodes are only used by the source modules, for example Xalan used 649MB for MDNodes after loading and linking, but the actual destination module only has 393MB of MDNodes. There are 649-393MB (40% of 649MB) not used. MDNodes belong to the Context, deleting modules will not release the

On Jun 21, 2013 1:19 AM, "Jeremy Lakeman" <Jeremy.Lakeman at gmail.com> wrote: > > Wouldn't it be simpler to name the metadata based on the hash of the content? Then you could use a normal reference to that metadata without needing to create a new type or teach the rest of llvm how to use it... Sounds reasonable (probably with some nice prefix to get these things a

The intent of this proposal is to speedup compilation of "-flto -g" for c++ programs. This is based on discussions with Adrian, David and Eric. --------------------------- Problem: A single class can be used in multiple source files and the DI (Debug Info) class is included in multiple bc files. The duplication of class definitions causes blow-up in # of MDNodes, # of DIEs, leading to

On Jun 21, 2013, at 10:18 AM, David Blaikie wrote: > On Fri, Jun 21, 2013 at 10:13 AM, Manman Ren <mren at apple.com> wrote: >> >> More details please :] >> What do you mean by "name the metadata"? Are you referring to the name field >> of the MDNode? > > Using named metadata rather than unnamed metadata. > > rather than having: > >

On Fri, Jun 21, 2013 at 10:13 AM, Manman Ren <mren at apple.com> wrote: > > More details please :] > What do you mean by "name the metadata"? Are you referring to the name field > of the MDNode? Using named metadata rather than unnamed metadata. rather than having: !llvm.hardref = !{metadata !"foo.h::myClass", !3, metadata !"bar.h:myEnum", !4} ...

On Tue, Nov 12, 2013 at 4:38 PM, Chandler Carruth <chandlerc at google.com>wrote: > > On Tue, Nov 12, 2013 at 4:29 PM, Manman Ren <manman.ren at gmail.com> wrote: > >> Hi All, >> >> In LTO, we load in the source modules and link the source modules into a >> destination module. >> Lots of MDNodes are only used by the source modules, for example

> On Oct 17, 2014, at 3:54 PM, Sean Silva <chisophugis at gmail.com> wrote: > > this seems like the classic situation where the someone comes to you asking for X, but what they really want is a solution to underlying problem Y, for which the best solution, once you actually analyze Y, is Z. On the contrary, I came into this expecting to work with Eric on parallelizing the backend,

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,

On Tue, Nov 12, 2013 at 4:29 PM, Manman Ren <manman.ren at gmail.com> wrote: > Hi All, > > In LTO, we load in the source modules and link the source modules into a > destination module. > Lots of MDNodes are only used by the source modules, for example Xalan > used 649MB for MDNodes after loading and linking, but the actual > destination module only has 393MB of

On Jun 20, 2013, at 2:58 PM, Eric Christopher wrote: > Hi Manman, > > On Thu, Jun 20, 2013 at 2:51 PM, Manman Ren <mren at apple.com> wrote: >> >> The intent of this proposal is to speedup compilation of "-flto -g" for c++ programs. >> This is based on discussions with Adrian, David and Eric. >> > > Thanks for bringing this back to the

Hi Manman, On Thu, Jun 20, 2013 at 2:51 PM, Manman Ren <mren at apple.com> wrote: > > The intent of this proposal is to speedup compilation of "-flto -g" for c++ programs. > This is based on discussions with Adrian, David and Eric. > Thanks for bringing this back to the list. The original thread was getting quite long. > --------------------------- > Problem: