search for: namedmetadata

...= call i8 @llvm.something(metadata !1) } See http://nondot.org/~sabre/LLVMNotes/EmbeddedMetadata.txt for more information. This metadata support is not useful if the auxiliary information is not referenced by any LLVM IR entity. This is a limiting factor. The proposed solution is to introduced NamedMetadata. The NamedMetadata is derived from GlobalValue. The NamedMetadata is an array of metadata nodes and metadata strings. @class.42 = ![ !5, !11, !2 ] ; NamedMetadata !5 = metadata !"int" !11 = metadata !"class.21 pointer" !2 = metadata ! {I32 8 } ; size The NamedMetadata el...

...t; } > > > See http://nondot.org/~sabre/LLVMNotes/EmbeddedMetadata.txt for more > information. > > This metadata support is not useful if the auxiliary information is > not referenced by any LLVM IR entity. This is a limiting factor. The > proposed solution is to introduced NamedMetadata. The NamedMetadata is > derived from GlobalValue. So, the idea is that some Analysis can take an LLVM IR entity, mangle information about that entity into a string, and then use that string to look up the associated NamedMetadata? An alternative to this would be to introduce a form of MDNode t...

...} > > > See http://nondot.org/~sabre/LLVMNotes/EmbeddedMetadata.txt for more > information. > > This metadata support is not useful if the auxiliary information is > not referenced by any LLVM IR entity. This is a limiting factor. The > proposed solution is to introduced NamedMetadata. The NamedMetadata is > derived from GlobalValue. The NamedMetadata is an array of metadata > nodes and metadata strings. > > @class.42 = ![ !5, !11, !2 ] ; NamedMetadata > > !5 = metadata !"int" > !11 = metadata !"class.21 pointer" > !2 = metadata...

...See http://nondot.org/~sabre/LLVMNotes/EmbeddedMetadata.txt for more >> information. >> >> This metadata support is not useful if the auxiliary information is >> not referenced by any LLVM IR entity.  This is a limiting factor. The >> proposed solution is to introduced NamedMetadata. The NamedMetadata is >> derived from GlobalValue. > > So, the idea is that some Analysis can take an LLVM IR entity, mangle > information about that entity into a string, and then use that string > to look up the associated NamedMetadata? No. I think, I used confusing example....

...mation. >>> >>> >>> >>> This metadata support is not useful if the auxiliary information is >>> >>> not referenced by any LLVM IR entity. This is a limiting factor. >>> The >>> >>> proposed solution is to introduced NamedMetadata. The >>> NamedMetadata is >>> >>> derived from GlobalValue. >>> >> >> >> So, the idea is that some Analysis can take an LLVM IR entity, mangle >> >> information about that entity into a string, and then use that string >> &gt...

On Mon, Jul 27, 2009 at 9:31 PM, Nick Lewycky<nicholas at mxc.ca> wrote: > Why not have a named GlobalValue with an MDNode initializer? How is this > different from what we had before? GlobalValue initializer accepts only Constants. - Devang

...nts, only to discover that if I did that then I couldn't use then as GV initializers. And it's not preposterous for them to be Constants. Functions are an example of a nameable zero-operand non-uniqued constant. Is there any particular benefit to keeping them out of Constant and adding NamedMetadata? Nick

...attached to MachineInstr's by now. Metadata can be bundled with Instruction class instances. The metadata attached to Instruction gets lost during code generation. Here is my question, is there a way to pass information attached to Instruction even further down to stages after code generation? NamedMetadata is a good example but it seems that it cannot be attached to Instruction or MachineInstr if I understand correctly. Is there something like DebugLoc which gets preserved all the way but more general than DebugLoc? Thank you in advance. -Bin -------------- next part -------------- An HTML attachmen...