[cfe-dev] Objective-C Code Generation

[Steve Naroff]

On Feb 24, 2008, at 11:14 AM, fjahanian wrote:

>
> 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
>> 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.
>
> 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.

I don't believe any abstraction is lost. You just have to be able to  
distinguish between AST's that reflect the user's source code from  
AST's that reflect the underlying ObjC object/runtime model.

That doesn't imply I think we should necessarily implement ObjC using  
AST transforms. If Chris would like to avoid the ObjC->C AST  
transforms (and go directly to LLVM IR), I trust his judgement. Since  
we've never done this, some experimentation is necessary. I'm sure  
David will keep us posted...

snaroff

> 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
> architecture.
>
> - Fariborz
>
>>
>>>> Are there any existing hooks for inserting this abstraction layer?
>>>> If
>>>> 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
>>> basis.
>>
>> @"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.
>>
>> David
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev