search for: mdnodeset

...ave special hooks for this debug info feature. Understand, that is why it is an option and comments from other people are welcome. > >> Other choices are: >> a> Keep a map in DwarfDebug >> Keep in mind that the map is used at many stages, and it has to be in sync with MDNodeSet. > > I'm not sure what you mean by "in sync with the MDNodeSet". When a node is created or RAUW, the map has to be updated. MDNodeSet keeps all live MDNodes and the map keeps part of MDNodeSet. > >> b> Generalize MDNode to be aware of hash (David can provide more...

...In LLVMContext, add “removeUnusedMDNodes" function It goes through OwnedModules and check if a MDNode is used by any of the modules, if not remove it. One implementation is to mark a visited MDNode used when traversing the module. After done traversing all modules, we can delete MDNodes in MDNodeSet that are not marked. In LTOCodeGenerator, add a vector of source modules that are added (these source modules will be linked with DestroySource mode). In LTOCodeGenerator:: compile_to_file, delete all source modules that are linked in, then call LLVMContext::removeUnusedMDNodes —> I can’t find...

...this isn't an appropriate layering & that LLVM's core IR metadata APIs cannot reasonably have special hooks for this debug info feature. > Other choices are: > a> Keep a map in DwarfDebug > Keep in mind that the map is used at many stages, and it has to be in sync with MDNodeSet. I'm not sure what you mean by "in sync with the MDNodeSet". > b> Generalize MDNode to be aware of hash (David can provide more details) My suggestion here, which I think is the only reason to really discuss this broadly (because it would be an LLVM metadata API feature) is r...

...veUnusedMDNodes" function > It goes through OwnedModules and check if a MDNode is used by any of the > modules, if not remove it. > One implementation is to mark a visited MDNode used when traversing the > module. After done traversing all modules, we can delete MDNodes in > MDNodeSet that are not marked. > > In LTOCodeGenerator, add a vector of source modules that are added (these > source modules will be linked with DestroySource mode). > In LTOCodeGenerator:: compile_to_file, delete all source modules that are > linked in, then call LLVMContext::removeUnusedMDN...

...; function >> It goes through OwnedModules and check if a MDNode is used by any of >> the modules, if not remove it. >> One implementation is to mark a visited MDNode used when traversing the >> module. After done traversing all modules, we can delete MDNodes in >> MDNodeSet that are not marked. >> >> In LTOCodeGenerator, add a vector of source modules that are added (these >> source modules will be linked with DestroySource mode). >> In LTOCodeGenerator:: compile_to_file, delete all source modules that are >> linked in, then call LLVMCont...

...MostGenericFPMath(MDNode *A, MDNode *B); static MDNode *getMostGenericRange(MDNode *A, MDNode *B); Comments are welcome on whether this violates any layering rule. Other choices are: a> Keep a map in DwarfDebug Keep in mind that the map is used at many stages, and it has to be in sync with MDNodeSet. b> Generalize MDNode to be aware of hash (David can provide more details) c> Extend MDNode to DINode and modify streamers (bitcode reader|writer, ll reader|writer) to be aware of DINode We can provide DINode::get(…) to create a DINode. DINode can have its own Profile function. Other sug...

...is a good idea > and would prefer either a or b below. a) is a much simpler solution. Any reason that why it is not a good idea? > >> Other choices are: >> a> Keep a map in DwarfDebug >> Keep in mind that the map is used at many stages, and it has to be in sync with MDNodeSet. >> b> Generalize MDNode to be aware of hash (David can provide more details) >> c> Extend MDNode to DINode and modify streamers (bitcode reader|writer, ll reader|writer) to be aware of DINode >> We can provide DINode::get(…) to create a DINode. DINode can have its own Pr...

...pecial' string) but any access of the node > 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 > > I personally prefer option b over a since it is...

...a good idea > and would prefer either a or b below. a) is a much simpler solution. > > Any reason that why it is not a good idea? > > > Other choices are: > a> Keep a map in DwarfDebug > Keep in mind that the map is used at many stages, and it has to be in sync > with MDNodeSet. > b> Generalize MDNode to be aware of hash (David can provide more details) > c> Extend MDNode to DINode and modify streamers (bitcode reader|writer, ll > reader|writer) to be aware of DINode > We can provide DINode::get(…) to create a DINode. DINode can have its own > Profile...

...good idea > and would prefer either a or b below. a) is a much simpler solution. > > Any reason that why it is not a good idea? > > > Other choices are: > a> Keep a map in DwarfDebug > Keep in mind that the map is used at many stages, and it has to be in sync > with MDNodeSet. > b> Generalize MDNode to be aware of hash (David can provide more details) > c> Extend MDNode to DINode and modify streamers (bitcode reader|writer, ll > reader|writer) to be aware of DINode > We can provide DINode::get(…) to create a DINode. DINode can have its own > Profi...

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

...e flag that it's a 'special' string) but any access of the node 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 I personally prefer option b over a since it is much cleaner. Thanks, Manman On...

...any access of the node >> 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 >> >> I personally prefer option b...

...ould prefer either a or b below. a) is a much simpler solution. > Any reason that why it is not a good idea? > >> >>> Other choices are: >>> a> Keep a map in DwarfDebug >>> Keep in mind that the map is used at many stages, and it has to be in sync with MDNodeSet. >>> b> Generalize MDNode to be aware of hash (David can provide more details) >>> c> Extend MDNode to DINode and modify streamers (bitcode reader|writer, ll reader|writer) to be aware of DINode >>> We can provide DINode::get(…) to create a DINode. DINode can have...

...gt; It goes through OwnedModules and check if a MDNode is used by any of >>> the modules, if not remove it. >>> One implementation is to mark a visited MDNode used when traversing >>> the module. After done traversing all modules, we can delete MDNodes in >>> MDNodeSet that are not marked. >>> >>> In LTOCodeGenerator, add a vector of source modules that are added >>> (these source modules will be linked with DestroySource mode). >>> In LTOCodeGenerator:: compile_to_file, delete all source modules that >>> are linked in...

...uch simpler solution. >>> >>> Any reason that why it is not a good idea? >>> >>> >>> Other choices are: >>> a> Keep a map in DwarfDebug >>> Keep in mind that the map is used at many stages, and it has to be in sync >>> with MDNodeSet. >>> b> Generalize MDNode to be aware of hash (David can provide more details) >>> c> Extend MDNode to DINode and modify streamers (bitcode reader|writer, ll >>> reader|writer) to be aware of DINode >>> We can provide DINode::get(…) to create a DINode. DIN...

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

...he 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 &...

...ither a or b below. a) is a much simpler solution. >> >> Any reason that why it is not a good idea? >> >> >> Other choices are: >> a> Keep a map in DwarfDebug >> Keep in mind that the map is used at many stages, and it has to be in sync >> with MDNodeSet. >> b> Generalize MDNode to be aware of hash (David can provide more details) >> c> Extend MDNode to DINode and modify streamers (bitcode reader|writer, ll >> reader|writer) to be aware of DINode >> We can provide DINode::get(…) to create a DINode. DINode can have its...

...gt; As I've said many times in email, I don't think this is a good idea and would prefer either a or b below. a) is a much simpler solution. > Other choices are: > a> Keep a map in DwarfDebug > Keep in mind that the map is used at many stages, and it has to be in sync with MDNodeSet. > b> Generalize MDNode to be aware of hash (David can provide more details) > c> Extend MDNode to DINode and modify streamers (bitcode reader|writer, ll reader|writer) to be aware of DINode > We can provide DINode::get(…) to create a DINode. DINode can have its own Profile funct...