Tom St Denis wrote: > Yeah, except putting all your functions in one file goes against the > very nature of proper software development strategies. That's not what I was advocating at all, just that marking non-externally visible functions as static is better than manually inlining. > Often the savings, especially on desktop/server class processors from > the minutia of optimizations possible at that level do not out weigh the > cost to the development process. But with LTO the development process doesn't change at all. The structure of the source into separate compilation units remains, and each unit is still individually compiled. It's just that some optimization and processing are delayed until the point which would traditionally be called linking. > For example, in my math library the modexp function calls an external > mul, sqr, and mod functions (well montgomery reduction but you get the > point). So even though they're not inlined (well they're big so they > wouldn't anyways) and you have the overhead of a call, the performance > is still 99% dominated by what happens inside the calls, not by the call > itself. In my case, my multipliers are fully unrolled/inlined since > that's where the performance is to be had. So it was worth the > readability cost (well they're machine generated anyways) for it. I see no reason why any of the above would change under LTO. > I question the sanity of a LTO step (if indeed that means it > re-organizes the object code at link time). It'll make debugging harder > when supposedly non-inlined code gets inlined, or other nasties (e.g. > picking up a constant from another module then removing dead code, etc). Debugging when a function is inlined is hard, yes, but that happens today already for a number of reasons. When it happens as a result of LTO it is no different than when it happens now. Ideally the debug information should be expressive enough that debugging an inlined function should be just as straightforward as the out-of-line version, and there are several competing approaches underway to move more towards that ideal. > I think most people would prefer their object files to be representative > of the compiler input. I don't see how that follows, as each LTO object file is still directly representative of the contents of its corresponding translation unit, they are just in a more raw form (IL) rather than being assembled machine code. If you don't want LTO nobody is going to ram it down your throat, just don't use -flto. Brian
