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.
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
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. 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 >
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 >> > >
On Apr 22, 2009, at 12:14 AM, Nick Lewycky wrote:> 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.I don't see a great need to support references to values in different functions.> 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?We can't break this. I'd suggest putting void-value'd stuff in a separate namespace, perhaps !123 ? That way they'd be numbered independently of the %'s. -Chris