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