Messages in this thread | | | Subject | Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers | From | Arjan van de Ven <> | Date | Mon, 02 Jan 2006 19:49:06 +0100 |
| |
> I'd be reluctant to trust gcc-4 to do the right thing in all cases. If the > compiler fails to inline functions in certain critical cases we'll suffer > some performance loss and the source of that performance loss will be > utterly obscure.
yet.. turning inline into a hint (which causes gcc to greatly bias towards inlining without making it absolute) was also opposed by either you or Linus. Forcing is ALSO wrong. For example it causes gcc to do inlining even for functions that use variable sized arrays ;(
the performance loss potential should not be overstated; unless the code can get a real advantage in optimizing due to constant arguments (eg the kmalloc example), there is not much to gain from inlining. A "call" is 1 cycle at most normally, unless the code inside the inline is highly trivial/small that's negligible. (eg anything that does port or mmio is already 100x more expensive, as is anything that gets a cache-miss or a branch predictor miss such as a loop).
> All those squillions of bogus inlines which you've identified are probably > mainly in code we just don't care about much. We shouldn't penalise > well-maintained code because of legacy problems in less well-maintained > code.
this is not a correct assumption as far as I can see. Especially for drivers, but also even for kernel/. I sent you a patch to fix the biggest offenders, and I can do more of that of course. But to some degree the end isn't in sight, esp if new code keeps introducing new bogus inlines.
Maybe the right approach is to start rejecting in reviews new code that uses inline inappropriately. (where "inappropriate" sort of is "more than 3 lines of C unless there is some constant-optimizes-away trick")
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |