
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>On Feb 12, 2014, at 9:23 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> wrote:</div><div><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div>Hi, Kyle. It looks like Clang does not perform this optimization, even under -O3 or -Oz. I can guess why: even though sending a message to nil will result in 0, it's still more work to call objc_msgSend, have <i>it</i> do the comparison to nil, and then have it clean things up properly to return 0. (In fact, you can poke at the <a href="http://www.opensource.apple.com/source/objc4/objc4-532.2/runtime/Messengers.subproj/objc-msg-x86_64.s">source</a> for objc_msgSend and see exactly how much work it is: not much, but still more than doing the check yourself.)</div></div></blockquote><div><br></div><div>Understood. Though I’m curious: is there a hard-and-fast rule against optimizations introducing function calls and/or branches where they would otherwise not appear?</div><div><br></div><div>Nonetheless, this optimization also introduces the possibility of involving the nil message handler (which AFAIK is undocumented), so there is a semantic difference as well as a performance difference.</div><br><blockquote type="cite"><div><div><br></div><div>I could see this being a valid optimization for -Os or -Oz mode, though, where the stated goal of optimization is to make the program fast <i>and</i> minimize code size. If you agree, you can file a bug at <a href="http://llvm.org/bugs/">http://llvm.org/bugs/</a>, or against Apple at <a href="http://bugreport.apple.com">http://bugreport.apple.com</a>.</div></div></blockquote><div><br></div><div>Will do. I might even gin up a patch myself; I'm on a bit of an exploratory kick.</div><div><br></div><div>Thanks,</div><div>--Kyle Sluder</div></body></html>