[cfe-dev] Objective-C Code Generation
fjahanian at apple.com
Sun Feb 24 11:14:06 PST 2008
On Feb 24, 2008, at 5:28 AM, David Chisnall wrote:
> Hi Chris,
> On 23 Feb 2008, at 19:06, Chris Lattner wrote:
>>> 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. 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
> 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.
clang has several consumers that rely on integrity of ASTs to reflect
the source language; pretty printer, dumper, rewriter are among them.
In future there will be more. Lowering AST to its c equivalent will
kill the abstraction needed by these consumers. It also makes
objective-c code gen. runtime dependent as Darwin and Gnu runtimes
have different rewuirements in many cases. Of course you can always
write an AST-to-AST translator for objective-c code gen. only. But
this will be just another Consumer and fits well with clang's
>>> Are there any existing hooks for inserting this abstraction layer?
>>> so, can someone point me in the right direction, and if not can
>>> someone suggest a good place to put them?
>> At this point, I'd suggest starting with the simple constructs (e.g.
>> the stand alone objc expressions like @"foo", add pointers to
>> interfaces, etc) and then move on the metadata. If you do each
>> patch cleanly and incrementally I don't expect a big problem. When
>> we start on codegen support for the next runtime, we can generalize
>> the code and figure out what abstractions are best on a case-by-case
> @"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;
> 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.
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
More information about the cfe-dev