search for: mdnode

Displaying 20 results from an estimated 606 matches for "mdnode".

2013 Nov 13
3
[LLVMdev] Proposal: release MDNodes for source modules (LTO+debug info)
...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 mo...
2013 Nov 13
2
[LLVMdev] Proposal: release MDNodes for source modules (LTO+debug info)
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 pos...
2013 Nov 13
0
[LLVMdev] Proposal: release MDNodes for source modules (LTO+debug info)
...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...
2013 Nov 13
0
[LLVMdev] Proposal: release MDNodes for source modules (LTO+debug info)
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 relea...
2011 Oct 17
2
[LLVMdev] Variable name from metadata
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...
2013 Nov 14
1
[LLVMdev] Proposal: release MDNodes for source modules (LTO+debug info)
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, e...
2013 Jun 20
9
[LLVMdev] Proposal: type uniquing of debug info for LTO
...-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...
2011 Oct 17
0
[LLVMdev] Variable name from metadata
...required information.                 const CallInst *CI = dyn_cast<CallInst>(Insn);                 int numoperands = CI->getNumArgOperands();                 for( unsigned i = 0; i != numoperands; ++i)                 {                   Value *v = CI->getOperand(i);                   MDNode *temp = (MDNode *)CI->getOperand(1) ;                   DIVariable DV(temp);//TO CHECK. remove later                   StringRef varName = DV.getName();                   const char *tmpvarname = varName.data();                   if( i == 1) //points to metadata for variable name                ...
2011 Dec 22
3
[LLVMdev] creating new Metadata
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...
2013 Nov 14
4
[LLVMdev] Proposal: release MDNodes for source modules (LTO+debug info)
.... > > > > 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 t...
2013 Jun 21
3
[LLVMdev] Proposal: type uniquing of debug info for LTO
...man Ren <mren at apple.com> wrote: > > 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 and how to keep it up-to-date when a MDNode is replaced. >>> --------------------- >>> Option a) a map in DwarfDe...
2013 Jun 21
0
[LLVMdev] Proposal: type uniquing of debug info for LTO
...t; wrote: >> >> 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 and how to keep it up-to-date when a MDNode is replaced. >>>> --------------------- >>>> Option a) a ma...
2013 Nov 13
2
[LLVMdev] Proposal: release MDNodes for source modules (LTO+debug info)
...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 speci...
2013 Jun 20
1
[LLVMdev] Proposal: type uniquing of debug info for LTO
...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 h...
2013 Jun 20
0
[LLVMdev] Proposal: type uniquing of debug info for LTO
...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...
2013 Jun 21
5
[LLVMdev] Proposal: type uniquing of debug info for LTO
...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...
2013 Nov 13
2
[LLVMdev] Proposal: release MDNodes for source modules (LTO+debug info)
...;>> 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. >>>> >>>> MD...
2013 Jun 20
2
[LLVMdev] Proposal: type uniquing of debug info for LTO
...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 h...
2013 Jun 21
3
[LLVMdev] Proposal: type uniquing of debug info for LTO
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? Then you could use a n...
2013 Jun 21
1
[LLVMdev] Proposal: type uniquing of debug info for LTO
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: > > !llvm.hardref = !{metadata !"foo.h::myClass", !3, metadata > !"bar.h:myEnum", !4} ... > !3 = ...; > !4 = ...; > > we could simply have: > > !llvm.hardr...