similar to: [LLVMdev] [Debug Info + LTO] Type Uniquing for C types?

> With C++'s ODR, we are able to unique C++ types by using type identifiers to > refer to types. > Type identifiers are generated by C++ mangler. What about languages without > ODR? Should we unique C types as well? > We can, but the identifier will need to be constructed on, likely, a language dependent basis to ensure uniqueness. > One solution for C types is to generate

On Fri, Oct 11, 2013 at 11:48 AM, Eric Christopher <echristo at gmail.com>wrote: > > With C++'s ODR, we are able to unique C++ types by using type > identifiers to > > refer to types. > > Type identifiers are generated by C++ mangler. What about languages > without > > ODR? Should we unique C types as well? > > > > We can, but the identifier

On Mon, Oct 14, 2013 at 4:14 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Mon, Oct 14, 2013 at 1:08 PM, Manman Ren <manman.ren at gmail.com> wrote: >> >> >> >> >> On Fri, Oct 11, 2013 at 12:40 PM, Eric Christopher <echristo at gmail.com> >> wrote: >>> >>> >> It depends upon the goals. If the

> > Since we don't have ODR, we may have macros defined differently for a struct > in a .h file, > thus having two versions of the struct from two different CU. It seems that > we can't assume > structs with the same name and defined in the same file/line/column are the > same. > Ah right sorry, I remember this. Also, macros are evil, just ask the modules guys :)

On Fri, Oct 11, 2013 at 12:07 PM, Eric Christopher <echristo at gmail.com>wrote: > > > > Since we don't have ODR, we may have macros defined differently for a > struct > > in a .h file, > > thus having two versions of the struct from two different CU. It seems > that > > we can't assume > > structs with the same name and defined in the same

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:

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

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

On Jun 20, 2013, at 3:55 PM, Manman Ren <mren at apple.com> wrote: > > 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

On Jun 20, 2013, at 5:39 PM, David Blaikie wrote: > 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

On Thu, Jun 20, 2013 at 4:45 PM, Manman Ren <mren at apple.com> wrote: > > On Jun 20, 2013, at 3:55 PM, Manman Ren <mren at apple.com> wrote: > > > 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

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 20, 2013, at 4:52 PM, David Blaikie wrote: > On Thu, Jun 20, 2013 at 4:45 PM, Manman Ren <mren at apple.com> wrote: >> >> On Jun 20, 2013, at 3:55 PM, Manman Ren <mren at apple.com> wrote: >> >> >> On Jun 20, 2013, at 2:58 PM, Eric Christopher wrote: >> >> Hi Manman, >> >> On Thu, Jun 20, 2013 at 2:51 PM, Manman Ren

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> wrote: >>> >>> On Jun 20, 2013, at 3:55 PM, Manman Ren <mren at apple.com> wrote: >>> >>> >>> On Jun 20, 2013, at 2:58 PM, Eric

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> wrote: >>>> >>>> On Jun 20, 2013, at 3:55 PM,

> > I think the easiest design you'll get for uniquing C types that are > named the same thing (i.e. type defined in a .h file) is to use the > name of the struct combined with the file (and possibly line/column) > as an identifier. If you want to unify by structure then you'll need > to do something the equivalent to the type hashing that we're > implementing in

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

On Jun 21, 2013, at 11:35 AM, Eric Christopher wrote: > On Thu, Jun 20, 2013 at 10:52 PM, Manman Ren <mren at apple.com> wrote: >> >> 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

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