[LLVMdev] metadata syntax

Duncan Sands baldrick at free.fr
Thu Apr 23 01:18:32 PDT 2009


Hi Nick,

> 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".

well... ok, if you must :)

> 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.

How can MDNodes made out of WeakVH's result in this?

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

To hold the graph of which type can alias which other?

I fear that metadata, being extremely flexible, is going to end up being
used for a gazillion different things simply because it's the easy solution
(it's already there), not because it's the right solution, resulting in a
big pile of ill-defined metadata mush floating around in the IR.  Any
thoughts on how to avoid that?

Ciao,

Duncan.

> 
> 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
> >>
> > 
> > 
> 
> 




More information about the llvm-dev mailing list