[LLVMdev] gcc like attributes and annotations

[Chris Lattner]

On Fri, 24 Feb 2006, Jakob Praher wrote:
> out of a matter of fact I am still using llvm version 1.5. I don't know
> how 1.6 works in this matter.

ok.

> When translating a complex c application to llvm bytecodes, some
> semantics are lost:
>
> Take for isntance the interesting attribute to put a variable in the
> thread local data section (.tdata), this would be interesting to have in
> llvm.
>
> like in GCC you write:
>
> int x __attribute__((section(".tdata")));
>
> however the llvm bytecode (llvm-gcc -S) does not show anything like this
> attribute.

LLVM 1.6 and the "new front-end" already handle this right.  Here's the 
bugzilla bug corresponding to it:
http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=659

> There is this Annotable base class, which is used to annotate a
> MachineFunction to a LLVM Function. Function support Annotable but
> GlobalVariable as of 1.5 not.
>
> I would generally be interested and could contribute to extending LLVM
> by allowing more Annotatinons than currently possible.
>
> Why not make things like Instructions Annotable too?
> For instance pointer creating Instructions, like alloca, malloc, ..
> would be nice if they could be Annotable and so one could add symbolic
> information to the type beeing used.

At one point in time, Value was annotatable.  The problem with this was 
two fold:

1. This bloat every value in the system, by adding an extra pointer.
2. These annotations would get stale and not be updated correctly.

The problem is basically that adding annotations really amounts to 
extending the LLVM IR, and making it look like something simple doesn't 
make it easier to deal with.  For example, if you add an "I'm special" 
attribute to an instruction, then the function is cloned by some pass, is 
that attribute copied or not?  What if it is deleted, moved, rearranged, 
etc?  Further, how can annotations be serialized to .ll files and .bc 
files?  In llvm, we always want "opt -pass1 -pass2" to be the same as "opt 
-pass1 | opt -pass2", which would break if annotations can't be serialized 
(which they can't currently).

As a historical curiosity, Function still needs to be annotatable due to 
the LLVM code generator relying on it.  This will be fixed in LLVM 1.8 
and Function will not be annotable anymore.

If you *really* just want per-pass local data, you should just use an 
std::map from the Value* to your data.

> %struct.A = type { int }
> %struct.B = type { int }
>
> BTW: How would one generate a type alias like the above through the LLVM
> API?

Add two entries to the module symbol table for the same Type using 
Module::addTypeName.

> But sometimes it would be interesting to actually get symbol information
> about a type beeing used, without the need for full featured debug
> information ala DWARF.

This isn't something you can do, this is far more tricky than you make it 
out to be. :)

> This could be also solved by introducing Annotable.
> For instance if the alloca/malloc/.. instruction would get an Anntation
> about a symbolic type which could look like:
>
> { ("x",int) }
>
> One could use the DEF/USE and operand information in the byte code to
> know which symbolic field was accessed for instance through getelementptr.

Again, this is effectively extending the LLVM IR.  Calling it an 
'annotation' doesn't make it simpler. :)  Also, the front-end would have 
to be modified to generate the annotation.

> I don't know how you feel about that, but I there would be many
> circumstances where Annotations could help getting more information out
> of the bytecode.

While I understand the general utility of annotations, the LLVM Annotation 
facility has several problems (some of which are described above) that 
make them not work well in practice.  Even if they did, they would still 
have the "updating" class of problems, which I'm not sure how to solve.

If you think that this is something that would be really useful, you 
can come up with solutions for these issues, and you're willing to 
implement it, then this is the right place to talk about the design of the 
new facility. :)

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/