search for: namedmdnode

...ersistent. > My only concern is with overloading a construct that wasn't designed > with that in mind, and currently isn't consistently treated in that way > even if it happens to work today at the module level. Yeah, I can't think of any use for something that would pull out NamedMDNodes for no reason. That said, if you want this to work, please audit the module cloner at the very least (it should copy the NamedMDNodes). But what would you do with llvm-extract? Should it keep a copy of every global metadata node that references a function? The same applies to bugpoint. What if...

On Jan 24, 2012, at 9:11 PM, Nick Lewycky wrote: > Yeah, I can't think of any use for something that would pull out NamedMDNodes for no reason. That said, if you want this to work, please audit the module cloner at the very least (it should copy the NamedMDNodes). > > But what would you do with llvm-extract? llvm-extract already copies over named metadata. > Should it keep a copy of every global metadata node t...

Hello, I'm a little confused by the definition of metadata node: does it have to contain different types of data ? And does a named metadata have to have a string name ? I know the named metadata can only contain metadatas e.g. !3=metadata !{metadata !1, metadata !2} Does it belong to NamedMDNode or MDNode ? Thanks! -- Best regards Hui Zhang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150224/7d02e3dd/attachment.html>

I looked at an earlier version. NamedMDNodes were linked after global values. Current trunk version links NamedMDNodes before that, though the comment says otherwise: "We do this after linking GlobalValues so that MDNodes that reference GlobalValues are properly remapped". see ModuleLinker::run in lib/Linker/LinkModules.cpp. If...

On Jan 24, 2012, at 1:35 AM, Chandler Carruth wrote: > On Wed, Jan 18, 2012 at 1:36 PM, Bill Wendling <wendling at apple.com> wrote: > Hello, > > This is a proposal for implementing "module flags". Please take a look at this and give any feedback you may have. > > Thanks! > -bw > > I have only one real comment -- this violates the contract and spirit

...e. For example, if a MDNode is "using" a User then optimizer can remove the User without bothering about what happens to the MDNode. Same way, If MDNode is attached to an Instruction then optimizer can mutate, delete or replace the Instruction while completely ignoring attached MDNode. NamedMDNode is a simple collection of metadata nodes at module level. By design NamedMDNode does not have any uses and it can not directly hold any values (use any values) other then MDNode, so there is not any reason for optimizer to worry about it. >> >> I think what you're really talking...

On Aug 4, 2011, at 11:30 AM, Xi Wang wrote: > I looked at an earlier version. NamedMDNodes were linked after global > values. Current trunk version links NamedMDNodes before that, though > the comment says otherwise: "We do this after linking GlobalValues so > that MDNodes that reference GlobalValues are properly remapped". see > ModuleLinker::run in lib/Linker/L...

...am wondering if someone can give me pointers to how to use the DI* classes defined in DebugInfo.h. In particular, I am confused about how to get a MDNode from the GlobalVariable's that hold the debug info so that they can be passed into the DI* classes, and the difference between MDNode and NamedMDNode in general. Thanks for your help. Alvin

...vm instructions. However, the metadata map is not getting updated > as expected. > For example, instead of the expected new entry If you look at PoolMDPass::runOnModule(), you'll see that the MDNodes are stored in a container (ValueToPoolNodes) and that they are added as operands to a NamedMDNode. I think you have to make your MDNodes operands of a NamedMDNode in order to get them to work properly. -- John T. > > !n = metadata !{some values} > > we are getting > > !n = metadata !{null} > > Do you know what might be wrong? Do we need to enter the MDNodes into &gt...

On Tue, Jan 24, 2012 at 12:02 PM, Bill Wendling <wendling at apple.com> wrote: > On Jan 24, 2012, at 1:35 AM, Chandler Carruth wrote: > > > On Wed, Jan 18, 2012 at 1:36 PM, Bill Wendling <wendling at apple.com> > wrote: > > Hello, > > > > This is a proposal for implementing "module flags". Please take a look > at this and give any feedback

...parameters? I tried to use the getVariables() function defined in DISubprogram, but it seemed to return an empty DIArray node when I ran my pass alone using opt. Do I need to enable any other analysis passes in order to populate the data? My related snippet of code is like the following: NamedMDNode *M_Nodes = M.getNamedMetadata("llvm.dbg.cu"); for (unsigned i = 0, e = M_Nodes->getNumOperands(); i != e; ++i) { DIArray SPs = CU.getSubprograms(); for (unsigned i = 0, e = SPs.getNumElements(); i != e; ++ i) { DISubprogram SP(SPs.getElement(i)); DI...

...mdnode. > > > AllSubprograms.push_back(Node); > > And follow AllSubprograms in DIBuilder::finalize() > > I traced through the code in DIBuilder::finalize(): *for* (*unsigned* i = 0, e = SPs.getNumElements(); i != e; ++i) { DISubprogram SP(SPs.getElement(i)); *if* (NamedMDNode *NMD = getFnSpecificMDNode(M, SP)) { SmallVector<Value *, 4> Variables; *for* (*unsigned* ii = 0, ee = NMD->getNumOperands(); ii != ee; ++ii) It looks as if getFnSpecificMDNode() is always returning NULL in my case - the body of the if statement never gets executed. > --...

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 the MDNodes into the

...; !0 = metadata !{metadata !"string", metadata !1, i32* @global) > > Notice that the `@global` argument is not metadata: it's an > `llvm::Constant`. In the new IR, these will be wrapped in a > `ValueAsMetadata` instance. > > 2. Operands of `NamedMDNode` (yes, they're different). > > !named = metadata !{metadata !0, metadata !1} > > These operands are always `MDNode`. > > 3. Attachments to instructions. > > %inst = load i32* @global, !dbg !0 > > Notice that we already skip the `metada...

...======== > > A number of APIs expect `MDNode` -- previously, the only referenceable > type of metadata -- but this patch (and the ones that will follow) have > referenceable metadata that *do not* inherit from `MDNode`. Metadata > APIs such as `Instruction::getMetadata()` and > `NamedMDNode::getOperand()` need to return non-`MDNode` metadata. > > To me, this change is a red flag This bothers me too -- which is why I highlighted it -- but I don't see any alternatives. It seems like a natural fallout of the rest of the proposal. > and points out a bit of a lie in the su...

...w to get a MDNode > from the GlobalVariable's that hold the debug info so that they can be passed > into the DI* classes, Now, MDNode is used to hold debug info. Which tool are you using to generate llvm IR with debugging information ? - Devang > and the difference between MDNode and NamedMDNode in > general.  Thanks for your help. > > Alvin > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- - Devang

Hi All, I have a question about named metadata, i.e. NamedMDNode. I have one dedicated named metadata node, say "clang.global.func.type", for conveying information about functions defined in each translation unit. In the module resulting from each translation unit, the dedicated (named metadata) node does not have redundancy. However, this dedicated...

...e debug info location like DILexicalBlock ,and insert !dbg appending an instruction. 2. LLVM::Instruction::setMetadata(...) => insert the metadta and !dbg appending an instruction. 3. DIBuilder::insertDeclare(...) => insert variable declare (like @llvm.dbg.declare) and metadata. 4. llvm::NamedMDNode::addOperand(...) => insert and Named Metadata. Like I can use above four function to insert metadata into bitcode. But I can't just insert a metadata. This problem is occur when I want to create an DISubprogram metadata into bc. I can't use above four function because this descript...

On Aug 4, 2011, at 8:21 AM, Xi Wang wrote: > Hi, > > It seems that current linker "drops" updated llvm::Value * references > in metadata. Here goes an example. We have a two-line source file > a.c: > > static int x; > void foo() { x = 1; } > > and a similar b.c: > > static int x; > void bar() { x = 1; } > > They both have an internal

...metadata !"foo.h::myClass", !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 &gt...