search for: mdnodes

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

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 MDNodes. One poss...

...gt;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 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 C...

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 MDNodes. There are 649-393MB (40% of > 649MB) not used. > > MDNodes belong to the Context, deleting modules will not releas...

Hi All,   Can we extract name of variable name from "MDNode" ?   1. Neither temp_MDNode->getName() nor temp_MDNode->getValueName() give me "global_int" which is name of a variable.   2. I tried below ways as well. DIVariable DV(mdnode1); Value *v = mdnode1->getOperand(0);//gives add 0x69   3. I have written below code to reach till variable name.        LLVMIname is

On Thu, Nov 14, 2013 at 5:19 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> Letting the module own MDNodes may not be a win for gold since it is going >> to create multiple copies of MDNodes that could be shared with Context >> owning MDNodes. >> >> For example, with debug info type uniquing, the type nodes can be shared >> across modules, but with module owning MDNodes, ea...

...-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 large memory requirement. As an example, SPEC xalancbmk requires 7GB of memory when compiled with -flto -g. With a preliminary implementation of type uniquing, the memory usage will be down to 2GB. In order to unique types, we have to break cycles in the MDNodes. A simple...

Closing this, found below links to get variable name.   http://groups.google.com/group/llvm-dev/browse_thread/thread/1a239f0d24db2b5c   http://markmail.org/message/fj5qg44vyjsdde7k#query:+page:1+mid:5zhmyncisenomcga+state:results           I could do following, to get the required information.                 const CallInst *CI = dyn_cast<CallInst>(Insn);                 int numoperands =

Hello, Thank you very much for the pointers. I am are able to create new MDNodes, filled with some constants, and attach them to llvm instructions. However, the metadata map is not getting updated as expected. For example, instead of the expected new entry !n = metadata !{some values} we are getting !n = metadata !{null} Do you know what might be wrong? Do we need to enter...

.... > > > > I have no idea is these sort of changes work for the gold plugin. > > The gold plugin calls lto_codegen_add_module/lto_module_dispose early. > So it looks like Chandler's idea would be a win for gold but a loss > for ld64 right now. > Letting the module own MDNodes may not be a win for gold since it is going to create multiple copies of MDNodes that could be shared with Context owning MDNodes. For example, with debug info type uniquing, the type nodes can be shared across modules, but with module owning MDNodes, each module will create its own copy of the ty...

...xtend Metadata (MDNode) to support MDHash" or something like that. I'd like to hear a rationale for wanting b first. I don't know (and can think of) any other users of this functionality right now. > We can add a weight to MDHash (other names are fine with me), to support multiple MDNodes with the same hash, but different weight. > Wait, what? This sounds like a bad idea. -eric > Thanks, > Manman > >> >> -eric >> >> >>> Thanks, >>> Manman >>> >>> On Jun 20, 2013, at 5:39 PM, David Blaikie wrote: >>>...

...ike the opcode for Instruction, to support TBAA, DI, and other types. Inside streamers (bc ll reader), we can create the specialized class according to the opcode. That requires a lot of changes too :( > >> We can add a weight to MDHash (other names are fine with me), to support multiple MDNodes with the same hash, but different weight. >> > > Wait, what? This sounds like a bad idea. Why? The weight is needed to differentiate a forward declaration vs. a definition, they both name the same class, but they are different. Thanks, Manman > > -eric > >> Thanks,...

...at 4:59 PM, Chandler Carruth <chandlerc at google.com> wrote: > Other options are: > 1> Using a different LLVMContext for the destination module, but it didn’t work out since Linker was not designed to work with different LLVMContexts for source vs destination. > 2> removeUnusedMDNodes checks if a MDNode is used in a different way (i.e use_empty() && !hasValueHandler()), but it does not remove MDNodes that form cycles. > > 3) Make the MDNode be owned by the module that uses it? > > MDNode is shared among modules so multiple modules can use it, if we specif...

...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 large memory requirement. >> >> As an example, SPEC xalancbmk requires 7GB of memory when compiled with -flto -g. >> With a preliminary implementation of type uniquing, the memory usage will be down to 2GB. >> >> In order to unique types, we ha...

...gt; 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 large memory requirement. > > As an example, SPEC xalancbmk requires 7GB of memory when compiled with -flto -g. > With a preliminary implementation of type uniquing, the memory usage will be down to 2GB. > > In order to unique types, we have to break cycles in...

...e list. The original thread was > getting quite long. > > --------------------------- > 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 > large memory requirement. > > As an example, SPEC xalancbmk requires 7GB of memory when compiled with > -flto -g. > With a preliminary implementation of type uniquing, the memory usage will be > down to 2GB. > > In order to unique types, we have to b...

...;>> 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 MDNodes. There are 649-393MB (40% of >>>> 649MB) not used. >>>> >>>> MDN...

...original thread was > getting quite long. > >> --------------------------- >> 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 large memory requirement. >> >> As an example, SPEC xalancbmk requires 7GB of memory when compiled with -flto -g. >> With a preliminary implementation of type uniquing, the memory usage will be down to 2GB. >> >> In order to unique types, we ha...

...t;> through the operand list would return the underlying MDNode from the > >> list (lookup via a map in LLVMContext, essentially). > >> > >> --------------------- > >> Options that are vetoed: > >> 1> Specialize Profile function for DI nodes to use MDNodeSet to support lookup. No need for a separate map. > >> 2> Extend the class hierarchy to have a class for DI nodes: > >> Value -- MDNode -- DINode > >> -- MDString > >> -- User -- Instruction -- BinaryOperator > >> > >&g...

...Class", !3, metadata > !"bar.h:myEnum", !4} ... > !3 = ...; > !4 = ...; > > we could simply have: > > !llvm.hardref.foo.h.myClass = ...; > !llvm.hardref.bar.h.myClass = ...; > > or something like that. From the documentation: NamedMDNode - a tuple of MDNodes. Despite its name, a NamedMDNode isn't itself an MDNode. NamedMDNodes belong to modules, have names, and contain lists of MDNodes. Our DI classes all wrap around a MDNode. Also during IR linking, NamedMDNode is handled differently. Did I miss something? Thanks, Manman > > > (assumi...