This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: reduce compilation times?

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

> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]