On Wed, Aug 15, 2007 at 11:05:35PM +0200, Segher Boessenkool wrote: > >>No; compilation units have nothing to do with it, GCC can optimise > >>across compilation unit boundaries just fine, if you tell it to > >>compile more than one compilation unit at once. > > > >Last I checked, the Linux kernel build system did compile each .c file > >as a separate compilation unit. > > I have some patches to use -combine -fwhole-program for Linux. > Highly experimental, you need a patched bleeding edge toolchain. > If there's interest I'll clean it up and put it online. > > David Woodhouse had some similar patches about a year ago.
Sounds exciting... ;-) > >>>In many cases, the compiler also has to assume that > >>>msleep_interruptible() > >>>might call back into a function in the current compilation unit, thus > >>>possibly modifying global static variables. > >> > >>It most often is smart enough to see what compilation-unit-local > >>variables might be modified that way, though :-) > > > >Yep. For example, if it knows the current value of a given such local > >variable, and if all code paths that would change some other variable > >cannot be reached given that current value of the first variable. > > Or the most common thing: if neither the address of the translation- > unit local variable nor the address of any function writing to that > variable can "escape" from that translation unit, nothing outside > the translation unit can write to the variable. But there is usually at least one externally callable function in a .c file. > >At least given that gcc doesn't know about multiple threads of > >execution! > > Heh, only about the threads it creates itself (not relevant to > the kernel, for sure :-) ) ;-) Thanx, Paul - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html