|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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
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
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
objc-language mailing list | email@hidden
Do not post admin requests to the list. They will be ignored.
|>Re: LLVM and Objective-C/C++ (From: Chris Lattner <email@hidden>)|
Visit the Apple Store online or at retail locations.
Copyright © 2011 Apple Inc. All rights reserved.