Re: Link-time optimzation

[Ian Lance Taylor <ian@airs.com>]

Robert Dewar <dewar@adacore.com> writes:

> Ian Lance Taylor wrote:
> 
> >>We spend a lot of time printing out the results of compilation as
> >> assembly language, only to have to parse it all again in the
> >> assembler.
> 
> I never like arguments which have loaded words like "lot" without
> quantification. Just how long *is* spent in this step, is it really
> significant?

[ It wasn't me that said the above, it was Richard Earnshaw. ]

I haven't measured it for a long time, and I never measured it
properly.  And I don't know how significant it has to be to care
about.  I would expect that it is on the order of 1% of the time of a
typical unoptimized compile+assembly, but I can't prove it today.

A proper measurement is the amount of time spent formatting the output
in the compiler, the amount of time spent making system calls to write
out the output, the amount of time the assembler spends making system
calls reading the input, and the amount of time the assembler spends
preprocessing the assembler file, interpreting the strings, looking up
instructions in hash tables, and parsing the operands.  Profiling will
show that the assembler stuff is a significant chunk of time taken by
the assembler, so the questions are: how much time does gcc spend
formatting and how much time do the system calls take?

I just tried a simple unoptimized compile.  -ftime-report said that
final took 5% of the time (obviously final does more than formatting),
and the assembler took 4% of the total user time, and system time took
16% of wall clock time.  Cutting those numbers in half makes 1% seem
not implausible to me, maybe even low.

I'm considering an unoptimized compile because that is where the
assembler makes the most difference--the compiler is faster and the
assembler output probably tends to be longer, and also an unoptimized
compile is when people care most about speed.  For an optimizing
compile, the assembler is obviously going to be less of a factor.

Ian