[cfe-dev] How to preserve struct member identifiers?
Chris Lattner
clattner at apple.com
Mon Feb 21 10:38:58 PST 2011
On Feb 7, 2011, at 12:41 PM, Steve Mokris wrote:
> I'm working on a set of function libraries which I'd like to be as self-documenting as possible --- so that, for example, if only the bitcode were available to the end user, the end user could readily deduce how to use these functions.
Hi Steve,
This is a common area of confusion with LLVM IR. LLVM has a structural type system, so the names on the IR types don't actually mean anything.
> I'd like to define some C structures to use as arguments. If I define a structure as follows:
> struct stringStructure {
> char *stringVariable;
> };
> Clang produces the following IR:
> %struct.stringStructure = type { i8* }
> ...which represents everything in my structure definition except the variable identifier `stringVariable`.
Right, the name doesn't mean anything, LLVM will print any {i8*} type with the same name regardless of what it was named in the source.
>
> I'd like to find some way to export the identifier into the generated LLVM IR, so that I can refer to it by name.
>
> I've tried adding the `annotate` attribute, as follows:
> char *stringVariable __attribute__((annotate("stringVariable")));
> ...but the annotation doesn't seem to make it through (the structure is still just defined as type { i8* }, and the literal "stringVariable" still appears nowhere in the IR).
>
> Why is this? Can I entice the `annotate` attribute on structure members to survive through to the generated IR, or is there some other way I can force structure member identifiers to be exposed? (I'd prefer not to have to include full debug info just to get this comparatively small piece.)
There isn't a good answer to this right now. OTOH, for LLVM 3.0 I do plan to completely revise the LLVM IR type system (for other reasons), which will fix this :)
-Chris
More information about the cfe-dev
mailing list