Andi, On Tue, May 5, 2009 at 1:49 AM, Andi Kleen <a...@firstfloor.org> wrote: > Xinliang David Li <davi...@google.com> writes: >> >> If the idea is generally accepted, I will prepare a series of patches >> and submit them to gcc trunk. > > I was reading your wiki page. Interesting idea. > > One aspect that wasn't clear to me on reading it was how different > compiler arguments for different files are handled. How would the > compiler compiling another source file know what special arguments > (like -I -D or special -f options) it needs? Or in what directory it > was compiled in for -I paths? Or do you assume that is always all the > same?
This is actually mentioned in the document. Please see the section about the module info record format. In each module info, the information about -I paths, -D/-Us are recorded. Those will be passed to the preprocessor when each module is processed. > > The other thing that wasn't clear to me was the worst case > behaviour. If there's a single large file x.c that has a function that > is called from 100 other small files with hot call sites then x.c > would be compiled 100 times, right? x.c as an auxiliary module, is never fully compiled. It is fully parsed and after inlining, it is discarded (function DFEed). > Is there something to mitigate > such worst case behaviour? Yes, there are related options to throttle worst case behavior. This problem will most likely exist in theory (very large cluster in dynamic call graph). For most of the applications I see, hot calls are limited intra module or small clusters. Thanks, David > > Thanks, > -Andi > > -- > a...@linux.intel.com -- Speaking for myself only. >
