In LLVM IR metadata is used to attach auxiliary information with
various IR constructs. Currently metadata information is represented
using MDNode and MDString. The metadata can refer to LLVM values but
these references are not counted as regular "uses" of these values
because metadata is maintained 'on the side'. This ensures that the
optimizer is not influenced by auxiliary information. For example,
!1 = { i32 42 }
define void @foo() {
%x = 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 element list contains MDString and MDNodes only. The
NamedMetadata is always implicitly typed as metadata. LLVM bitcode
reader and writer will keep track of NamedMetadata in a Module. A
module can use metadata that is not listed in any NamedMetadata value.
A module can have multiple NamedMetadata values. NamedMetadata
implicitly uses AppendingLinkage. A NamedMetadata value has zero
uses.
The NamedMetadata can be used to describe Front End specific types for
the optimizer's use. Another potential use is to encode debug
information for a global variable. I do not intend to make @llvm.used
a NamedMetadata value.
-
Devang
On Jul 27, 2009, at 10:10 AM, Devang Patel wrote:> In LLVM IR metadata is used to attach auxiliary information with > various IR constructs. Currently metadata information is represented > using MDNode and MDString. The metadata can refer to LLVM values but > these references are not counted as regular "uses" of these values > because metadata is maintained 'on the side'. This ensures that the > optimizer is not influenced by auxiliary information. For example, > > !1 = { i32 42 } > > define void @foo() { > %x = 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.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 that has a designated Value that it's associated with. Then, for any given Value, one could look up all the Metadatas(?) associated with it.> 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 element list contains MDString and MDNodes only. The > NamedMetadata is always implicitly typed as metadata. LLVM bitcode > reader and writer will keep track of NamedMetadata in a Module. A > module can use metadata that is not listed in any NamedMetadata value. > A module can have multiple NamedMetadata values. NamedMetadata > implicitly uses AppendingLinkage.And DefaultVisibility and a default Section and an Alignment of 1? GlobalValues carry some amount of baggage here. Dan
On Mon, Jul 27, 2009 at 1:13 PM, Dan Gohman<gohman at apple.com> wrote:> > On Jul 27, 2009, at 10:10 AM, Devang Patel wrote: > > >> In LLVM IR metadata is used to attach auxiliary information with >> various IR constructs. Currently metadata information is represented >> using MDNode and MDString. The metadata can refer to LLVM values but >> these references are not counted as regular "uses" of these values >> because metadata is maintained 'on the side'. This ensures that the >> optimizer is not influenced by auxiliary information. For example, >> >> !1 = { i32 42 } >> >> define void @foo() { >> %x = 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. > > 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. The idea is to provide a way to have metadata that is not directly used by any LLVM IR entity. Here the metadata entity can itself use any other LLVM IR entity. For example ; ModuleID = 'blah.c' !1 = { i32 459008, metadata !"blah.c", "b", i32 4, i32 6 } !2 = { i32 458804, metadata !"blah.c", "a", i32 4, i32 6, i32 %a } a = global i32 42 define void @foo() { call void @llvm.dbg.declare(!1) } --- Here !1 and !2 encodes debug info for a local variable 'b' and global variable 'a' respectively. !1 is one of the llvm.dbg.declare argument so it is seen any LLVM IR walker. However, !2 is "invisible" here. The proposal is to introduce @llvm.dbg.gvs = ![ !2 ] where llvm.dbg.gvs provides an anchor for such floating metadata encoding global variables. One could encode type information using such floating metadata for optimizer's use. For example, %struct.mystruct = type { i32, i32 } @mm = common global %struct.mystruct zeroinitializer !11 = metadata !{ metadata !"typename", i32 %size, %struct.mystruct @mm }; [#uses=0]> An alternative to this would be to introduce a form of MDNode that > has a designated Value that it's associated with. Then, for any > given Value, one could look up all the Metadatas(?) associated > with it. > >> 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 element list contains MDString and MDNodes only. The >> NamedMetadata is always implicitly typed as metadata. LLVM bitcode >> reader and writer will keep track of NamedMetadata in a Module. A >> module can use metadata that is not listed in any NamedMetadata value. >> A module can have multiple NamedMetadata values. NamedMetadata >> implicitly uses AppendingLinkage. > > And DefaultVisibility and a default Section and an Alignment of 1? > GlobalValues carry some amount of baggage here.I checked these three. The code generator does not generate any code for these NamedMetadata so we can just use vanilla default values here without any harm. - Devang
Devang Patel wrote:> In LLVM IR metadata is used to attach auxiliary information with > various IR constructs. Currently metadata information is represented > using MDNode and MDString. The metadata can refer to LLVM values but > these references are not counted as regular "uses" of these values > because metadata is maintained 'on the side'. This ensures that the > optimizer is not influenced by auxiliary information. For example, > > !1 = { i32 42 } > > define void @foo() { > %x = 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 element list contains MDString and MDNodes only. The > NamedMetadata is always implicitly typed as metadata. LLVM bitcode > reader and writer will keep track of NamedMetadata in a Module. A > module can use metadata that is not listed in any NamedMetadata value. > A module can have multiple NamedMetadata values. NamedMetadata > implicitly uses AppendingLinkage. A NamedMetadata value has zero > uses. > > The NamedMetadata can be used to describe Front End specific types for > the optimizer's use. Another potential use is to encode debug > information for a global variable. I do not intend to make @llvm.used > a NamedMetadata value.Why not have a named GlobalValue with an MDNode initializer? How is this different from what we had before? Nick
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