site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com FYI ... found a short-term solution ... and some interesting things ... ProcessPixel->CopyBitRange->__rlwimi Since, by definition: 1) An inline function is short 2) Its definition must be available to anyone who calls it HTH, -Steve _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... At 10:03 AM -0400 10/9/06, Chris Edgington wrote: 1) No inlining at all happens unless optimization is enabled - regardless of the always_inline attribute. Yup, I filed a bug on that and it was closed as "works ad designed" -- seem the compiler folks, consider inlining an "optimization". In my case I had some C++ inline functions for pixel manipulation that called an inline utility function that evaluated to a compiler intrinsic. With optimizations off, this evaluated to 5 levels of function calls instead of a single instruction -- since this code is called 3 times per pixel, performance was degraded to the point it was no longer usable. I eventually had to resort to #define instead of inline for performance-critical code -- throwing away the type safety an inline function provides. Despite the compiler folks objections, there really does need to be an inline_dammmit attribute. 2) By default - an inlined function will also have a regular non-inlined copy in the object file. So - the short-term answer is to redefine __INLINE as "extern inline __attribute((always_inline))" and to build with optimizations enabled. Ultimately, however, I will likely need to change the prorotypes and function definitions to be static - so they work whether or not they are inlined. Actually, the only thing inline means is that it's OK if there are multiple definitions of a function and the linker shouldn't complain. I believe is that your problem is that your prototypes aren't inline -- you MUST fix at least that -- otherwise, the non-inlined prototype will take precidence over the inline definition. I always define inline functions in their header (with no separate declaration). If the inline keyword is in the declaration, there is no need to declare them static -- in fact this will cause code bloat if they are referenced from multiple files and not inlined. Simply using inline will cause the linker to keep just one implementation, but for this to happen, all declarations must be inline. This email sent to site_archiver@lists.apple.com