Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers

[Matt Mackall <mpm@selenic.com>]

On Thu, Jan 05, 2006 at 11:55:13PM +0100, Ingo Molnar wrote:
> 
> * Matt Mackall <mpm@selenic.com> wrote:
> 
> > > I don't believe it is actually all _that_ volatile. Yes, it would be a 
> > > huge issue _initially_, but the incremental effects shouldn't be that big, 
> > > or there is something wrong with the approach.
> > 
> > No, perhaps not. But it would be nice in theory for people to be able 
> > to do things like profile their production system and relink. And 
> > having to touch hundreds of files to do it would be painful.
> 
> we can (almost) do that: via -ffunction-sections. It does seem to work 
> on both the gcc and the ld side. [i tried to use this for --gc-sections 
> to save more space, but that ld option seems unstable, i couldnt link a 
> bootable image. -ffunction-sections itself seems to work fine in gcc4.]

Yeah, we've been talking about --gc-sections for years. It'd be nice
if we could work the build system in that direction with this
profiling concept.

(I suspect something silly happened in your test like dropping the
fixup table, btw.)

> i think all that is needed to reorder the functions is a build-time 
> generated ld script, which is generated off the 'popularity list'.
> 
> so i think the two concepts could nicely co-exist: in-source annotations 
> help us maintain the popularity list, -ffunction-sections allows us to 
> reorder at link time. In fact such a kernel could be shipped in 
> 'unlinked' state, and could be relinked based on per-system profiling 
> data. As long as we have KALLSYMS, it's not even a big debuggability 
> issue.

I'm still not sure about in-source annotations for popularity. My
suspicion is that it's just too workload-dependent, and a given
author's workload will likely be biased towards their code.

-- 
Mathematics is the supreme nostalgia of our time.