[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