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 | Thu, 29 Dec 2005 15:54:09 +0100 |
| |
> I don't care too much whether we put always_inline or inline at the function > we _really_ want to inline. But all others shouldn't have any inline marker. > So instead of changing the pretty useful redefinitions we have to keep the > code a little more readable what about getting rid of all the stupid inlines > we have over the place?
just in drivers/ there are well over 6400 of those. Changing most of those is going to be a huge effort. The reality is, most driver writers (in fact kernel code writers) tend to overestimate the gain of inline in THEIR code, and to underestimate the cumulative cost of it. Despite what akpm says, I think gcc can make a better judgement than most of these authors (probably including me :). We can remove 6400 now, but a year from now, another 1000 have been added back again I bet.
You describe a nice utopia where only the most essential functions are inlined.. but so far that hasn't worked out all that well ;) Turning "inline" back into the hint to the compiler that the C language makes it is maybe a cop-out, but it's a sustainable approach at least.
> I think many things we have static inline in headers > now should move to proper out of line functions.
I suspect the biggest gains aren't the ones in the headers; those tend to be quite small and often mostly optimize away due to constant arguments (there may be a few exceptions of course), and also have been attacked by various people in the 2.5/2.6 series before. It's the local functions that got too many "inline" hints.
- 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/
| |