Will the typical compiler inline a C function that makes one or more Objective-C method calls? E.g.:
NSUInteger AACStringGetLength(NSString *string) { return [string length]; }
Bonus points for a thorough proof with explanation.
What other things besides recursion might prevent the compiler from inlining a C function?
Asked
Active
Viewed 77 times
0

ma11hew28
- 121,420
- 116
- 450
- 651
-
What makes you think using functions is [any different from methods](http://stackoverflow.com/questions/8194504/does-llvm-convert-objective-c-methods-to-inline-functions). Inlining cannot happen in a dynamic context, and this is exactly a dynamic context. Besides, what benefit would inlining that call serve? You're still going to have an unoptimizable message send. If you want to see what inlining can do for you, try to ask about inlining the IMP of a method. – CodaFi Oct 09 '13 at 16:14
-
No, it's not. It's no problem for the compiler to compile "NSUInteger theLength = AACStringGetLength (myString);" as if you had written "NSUInteger theLength = [myString length];". – gnasher729 Apr 09 '14 at 17:34
1 Answers
2
AACStringGetLength()
can be inlined into its callers assuming the other requirements of inlining are satisfied. There's nothing about calls to Objective-C methods that prevents inlining of C functions.
Of course Objective-C methods cannot be inlined themselves, because the compiler cannot know that there is no unusual dynamic dispatch going on.
Things that can prevent inlining include:
- the caller and callee are in different translation units (i.e. different source code files), unless you are using link-time optimization of some sort
- the caller's code might end up "too big" after inlining according to the compiler's inlining heuristics
- the callee performs control flow that is too complicated for the compiler's inlining machinery to handle so it gives up

Greg Parker
- 7,972
- 2
- 24
- 21