Mailing Lists: Apple Mailing Lists
 Image of Mac OS face in stamp
Re: LLVM and Objective-C/C++
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LLVM and Objective-C/C++

Chris, I'll need to review your paper, but the challenges for Objective-C are significant with regard to inlining. I do however like to think that the challenges simply make the problem more interesting :-)

The smallest objects are in fact not objects. Long ago we tried objects for points & rects & ranges & stuff, but found them to be too expensive for heap allocation and so they already are "inlined" structs simply by the fact of still being structs. We've even been known to tweek ABIs to allow certain sized structures to be returned directly in registers for the sheer pleasure of the resulting performance.

Given that allocation is not in the language and that we have this often used idiom of "substituting on init", it means that the following code:
WhatsIt *wi = [[WhatsIt alloc] init];
[wi anything];
[wi more];
cannot be easily transformed into a stack allocated object or the code from "anything" and "more" inlined and pipelined etc.

The problems... well, you understand that categories can override implementations... do you know about poseAs: that can take over the class itself? Monomorphic optimizations are similarly hard - and are worse because of forwarding - every class has a trivial (raising) implementation of forward:: and there are several proxy "root" classes in actual use that make the type analysis hard.

If you're going to be spending some time on this subject we should talk. I actually do share your optimism that well written programs can be detected and appropriate optimizations performed at runtime.

Blaine

On Dec 23, 2003, at 9:29 PM, Chris Lattner wrote:

On Tue, 23 Dec 2003, Timothy J. Wood wrote:
Worse is the not completely uncommon idiom of:
This is used (as a last resort, but still used) to work around bugs
in Apple's frameworks (after making an appropriate Radar entry and
tagging the source with the Radar # of course :).

Like I said, I don't know a whole lot about ObjC, but this kind of stuff
happens in other languages too...

There are cases where this is used more politely to do fun runtime
tricks; all of these seem like they'd mess up interprocedural analysis.

It won't mess up the analysis, it will just cause the spiffy
transformations to be disabled for this case. I have an overactive
imagination, and am underinformed, but I imagine that the most amount of
payoff optimizing ObjC programs will come from the "small objects" like
points and other high-overhead but low-semantic value objects. The "big
objects" like the application or the GUI window class will probably be
beyond the capabilities of the analysis anyway, but that's ok if you get
the little ones.

If you're interested, the memory analysis we use to do a lot of these
transformations is called "Data Structure Analysis", it's described in
this paper:
http://llvm.cs.uiuc.edu/pubs/2003-04-29-DataStructureAnalysisTR.html

One of the things that makes it unusual is that it correctly handles all
manner of incomplete programs: it can analyze libraries, programs with
dynamically loaded code, single translation units, etc. Basically it
keeps track of when "unknown" things can happen to memory and remembers it
so that the transformations will not hack on something that might be
noticed by the end user. If it cannot determine the target of an indirect
call (or cannot determine it precisely enough), that will effectively
disable any transformations to memory objects accessible through that
function pointer.

The nice thing about the analysis is that it does it on a very
fine-grained level. If you pass one binary tree through the code above,
it won't get transformed. If another part of the code uses distinct
instances of the same binary tree, but doesn't do anything that confuses
the analysis, the safe code can still be transformed.

Note that this is very important in C derivative languages where
effectively arbitrary type violations can happen at any time and you have
to correctly preserve program behavior. ObjC manifests these problems in
different ways perhaps, but they are the same problems. Also, techniques
like 'idiom recognition' can be used to handle "common" special cases like
the above without losing precision if it is important enough to worry
about...

-Chris

--
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/
_______________________________________________
objc-language mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/objc-language
Do not post admin requests to the list. They will be ignored.
_______________________________________________
objc-language mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/objc-language
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: LLVM and Objective-C/C++ (From: Chris Lattner <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.