I'm fairly certain that it doesn't do cross-translation-unit inter-procedure analysis, so it can't tell if, for example, the function from another file that you call does anything special that would make the removal of a retain before passing the object to the function an invalid optimization.
It doesn't know that the object is only used in a thread-local context, so in many cases (eg, function args) it might not be able to assume that there is no concurrent refcounting action going on elsewhere, which eliminates other optimizations.
By definition, compilers have to be conservative about what callers can do, when humans can simply say "This function is not thread safe", or similar.
This is one reason that "real" GC is generally used instead of reference counting in all high performance garbage collected language. (In throughput-oriented systems, the GC is even a stop-the-world GC, since that removes quite a bit of concurrency/atomic operation overhead).
The other big one is that you need a garbage collector anyways if you want things to work in the presence of cycles.
EDIT: Perhaps someone with a Mac and access to this compiler can post some output of code with this feature enabled. I'd be curious to see what sort of output the compiler actually gives.
Disclaimer: I haven't actually tried playing with this yet, or read the docs, so this is pure speculation:
It may not need to do any kind of complicated proving or cross-unit analysis, and instead opt to simply rely on the fact that every good Objective-C citizen follows the same social naming conventions. Things coming back from methods with "alloc", "copy", or "new" in the name are owned by the current method and need to be disposed of properly (release it at the end of the method, or if it escapes this method, add it to the autorelease pool). Everything else can be assumed to be taken care of and we need only bump the retain count if it's getting assigned to something with a scope larger than the current method.
It wouldn't catch everything, but it could be made predictable in behavior and eliminate a large percentage of the boilerplate.
It doesn't know that the object is only used in a thread-local context, so in many cases (eg, function args) it might not be able to assume that there is no concurrent refcounting action going on elsewhere, which eliminates other optimizations.
By definition, compilers have to be conservative about what callers can do, when humans can simply say "This function is not thread safe", or similar.
This is one reason that "real" GC is generally used instead of reference counting in all high performance garbage collected language. (In throughput-oriented systems, the GC is even a stop-the-world GC, since that removes quite a bit of concurrency/atomic operation overhead).
The other big one is that you need a garbage collector anyways if you want things to work in the presence of cycles.
EDIT: Perhaps someone with a Mac and access to this compiler can post some output of code with this feature enabled. I'd be curious to see what sort of output the compiler actually gives.
This speculation is annoying :)