[cfe-dev] Objective-C Code Generation

[Chris Lattner]

>>>
>>> I imagine the easiest way of getting this working is to
>>> transform the Objective-C AST into a pure-C AST with calls to the
>>> relevant runtime libraries.
>>
>> This is the way that GCC works, but I don't think it is really the
>> best way.  I'd much rather have the clang codegen module directly
>> produce the LLVM IR for the constructs it needs.  I don't anticipate
>> that this will be a problem for metadata or other objc constructs.
>
> I am not completely sure what would be gained by doing this.  Unlike  
> C+
> +, every Objective-C construct maps cleanly to a C construct.
> Objective-C objects are C structures, Objective-C message sends are C
> function calls (and methods are just C functions with their pointers
> added to the class structure), and so on.

And all of them map onto LLVM IR :)

> If work has already been
> done to transform these C constructs into LLVM IR then it seems like
> there would be some significant code duplication to do the same for
> Objective-C.
>
> I don't mind generating LLVM IR (I've already written code which
> generates code targeting the GNU runtime from GNU Lightning), but I'm
> not sure what the benefit would be.

Please see Fariborz's response, it is exactly right.  If nothing else,  
multiple levels of translation slow down compile time.

> @"foo" is actually decidedly non-trivial from a code-generation
> perspective.  It needs to be expanded to an object, which is a
> structure of the form:
>
> {
> 	Class isa;
> 	char * c_string;
> 	unsigned int length;
> }

Ok, but it isn't hard to generate any of this in LLVM IR.  It's  
probably less code than setting up all the C AST types etc.

> Where the class pointed to by isa is determined at compile-time and
> resolved at runtime (both GNUstep and Cocoa define this as their own
> constant string representation (an NSString subclass).  It's hard to
> get something like this right until you have classes being generated
> correctly, which is probably where I'll start.

Ok!  If it's easier to start with defining simple interfaces, go for  
that, starting with @"foo" was just a suggestion,

-Chris