This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: Fix other/44566
Quoting Mark Mitchell <mark@codesourcery.com>:
I know this may be perceived as the words of someone who vary rarely
bootstraps the compiler anymore, but I believe that bootstrap speed per
se is nearly irrelevant. Compile-time is not irrelevant; we care what
the user experience is like. But to the extent bootstrap time is
independent of compile-time, I don't think we should care. (OK, I think
we should care about making it 10x greater, but not about making it 25%
greater.)
If that's 25% bootstrap time increase to get rid of the
FIRST_PSEUDO_REGISTER macro, I'll have to disagree.
The reason is that I think that (a) bootstraps are fast enough that it
doesn't make a whole lot of difference, and (b) building the run-time
libraries and running tests takes much more time than the bootstrap per
se.
building run-time libraries is part of the bootstrap. And building the
stage1 libraries suffers from a slow compiler which didn't get the benefit
of WHOPR/LTO optimizations.
C++ conformance issues often pop up when building stage2. So if the
compiler we built in stage1 is slow, that means building stage1 libraries
and the stage2 compiler is slow; the stage1-built compiler is an important
factor in the turn around time.
And, as for the bootstrap per se, I suspect that configure/link
overhead will dominate soon, if it doesn't already; configure and link
steps are (currently) serial, so cannot take advantage of massively
parallel systems in the way that the rest of the build process can.
I have often more than one bootstrap going on, so my build scripts generally
use make "-j5 -l 7" to get an even load distribution across four cores;
I could happily use a 48-core machine for my bootstraps, if it wasn't that
horrendously expensive to buy. Oh, and if bootstrap bloat caused it to
be fully loaded, it'd likely draw a lot of power, too.
So, concretely, carrying LTO/WHOPR overhead during the compiler build
itself to me seems OK if that gets us a better compiler and user's can't
tell the difference. In fact, we probably want to turn on LTO/WHOPR by
default once we feel it's sufficiently reliable since presumably we'll
get better code that way, no matter how the compiler is structured.
The worst performance hit is probably when using stage1 to build the
stage1 libraries and the stage2 compiler, as a compiler built with -O0
is used
to do LTO/WHOPR.
This will be worse if this -O0 built compiler has a lot of target hooks
in performance critical paths.
I'm not saying that it will definitely be unacceptable. But I'm saying that
we don't know if the performance hit will be acceptable till we can measure
it.