> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
