[LLVMdev] metadata syntax

[Nick Lewycky]

Duncan Sands wrote:
> Hi Nick,
> 
>> I'm looking for input into the syntax for future metadata work. The plan 
>> is to make MDNodes hold a list of WeakVHs which will allow us to track 
>> metadata associated with values even through calls to 
>> ReplaceAllUsesWith. It also means that you can refer to other Values in 
>> the program, including instructions in another Function.
>>
>> That's where the problems begin. There's currently no way in llvm 
>> assembly to refer to instructions in another function, though that's not 
>> hard to solve; I propose "@func/%tmp" as the syntax. The harder problem 
>> is how to express references to void instructions (stores, branches, 
>> switches) which historically have not been allowed to have names since 
>> they could never be referred to.
> 
> why do you need to refer to instructions in different functions,
> and instructions with no names?  I'm kind of lost as to what the
> purpose of this is.

It'd be nice to say "this StoreInst doesn't overlap that StoreInst" in a 
metadata. Or perhaps "here's the likely values for this SwitchInst".

I have only weak ideas for how interprocedural metadata could be used, 
but it's clear that an MDNode made out of WeakVH's could hold one, which 
is why I'd like to get a syntax for them. It's certainly something that 
could wait until we have a client, but I was hoping to not make multiple 
different syntaxes/bitcode formats that we would have to support in the 
future.

The first client for metadata I have in mind for metadata is TBAA.

Nick

> 
> Ciao,
> 
> Duncan.
> 
>> The obvious solution is to let them have names. The trouble is that this 
>> breaks .ll syntax for any program that's using old-style anonymous 
>> instructions. For example:
>>
>> define i32 @foo(i32* %ptr) {
>>    add i32 1, 2             ; %1
>>    store i32 0, i32* %ptr   ; previously ignored, now %2
>>    add i32 3, 4             ; previously %2, now %3
>>    ret i32 %2    ;; illegal! refers to the store not the add
>> }
>>
>> Is this okay? Or do we need to come up with a different solution? Any 
>> suggestions?
>>
>> Nick
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
> 
>