[LLVMdev] metadata syntax

[Nick Lewycky]

Duncan Sands wrote:
> 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?

A WeakVH is just a fancy Value*. Unlike the instruction stream, there's 
no restrictions on what Values it can hold at a given point, and I don't 
see any good reason to add them. Saying "we couldn't think of a syntax 
for the .ll file" is a terrible reason, but at least it's honest.

>> The first client for metadata I have in mind for metadata is TBAA.
> 
> To hold the graph of which type can alias which other?

Almost, since llvm::Type refers to multiple high-level types anyways. 
You could store a piece of metadata that associates the StoreInst with a 
number for the high-level type, then the graph relating those numbers 
would be 'elsewhere'. (No, I haven't designed how TBAA ought to work.)

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

My fear was that nobody would use metadata. :)

The answer is that it's meant to be the easy solution in cases where you 
just want to pass data about the instruction stream through the IR, 
without actually having instructions. Some folks might try to use 
metadata instead of just creating an analysis with a map, in which case 
we'll have to catch that on review like we do with any other design 
problem. I just don't think metadata is that special.

Nick

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