This is the mail archive of the
mailing list for the GCC project.
Re: Skipping assembler when producing slim LTO files
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Ian Lance Taylor <iant at google dot com>, Andi Kleen <andi at firstfloor dot org>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Wed, 24 Sep 2014 18:32:27 +0200
- Subject: Re: Skipping assembler when producing slim LTO files
- Authentication-results: sourceware.org; auth=none
- References: <20140924054651 dot GB5371 at kam dot mff dot cuni dot cz> <878ul96pnx dot fsf at tassilo dot jf dot intel dot com> <CAKOQZ8zCs8ZjGP3JWw6HVNXGS0junJn1BuvnMXmK8Ou8WHEnvg at mail dot gmail dot com> <20140924161906 dot GA26922 at atrey dot karlin dot mff dot cuni dot cz>
> > On Wed, Sep 24, 2014 at 7:47 AM, Andi Kleen <firstname.lastname@example.org> wrote:
> > >
> > > I wonder how hard it would be to fix simple-object to be able to create
> > > from scratch. From a quick look it would be mostly adding the right
> > > values into the header? That would need some defines per target.
> > It could be done, of course. It would mean maintaining a new set of
> > tables and updating them for each target. The specific table to use
> > would depend on the command line options. It turns into yet another
> > data structure to update.
> Yep, i think the crtstuff hack is pretty good for now (well under assumption
> I won't have too hard time to get it working in the driver). I think the only
> real blocker is the lack of simple-object API to create the two common
> symbols we need to make the object fiels compliant. I really hope Ian
> will help me on this, please;)
Just for some data, I did compile time comparsion at libreoffce
My general plan is to try to make LTO compile time faster than non-LTO and
possibly clang's on my setup (i.e. with WHOPR parallelism). It is already
faster than clan'g LTO. Also SPEC build times are now faster than non-LTO
Libreoffice shows that GCC needs about twice as much of system time. According
to profiles, good part is the ugly way we pass stuff down to assembler and
other part is memory use during the copmilation stage.
I fixed most of the botlenecks seen in GCC 4.9 - ineffeciencies in hashing
for streaming, unnecesary initialization of the backend, inliner and other
Funilly enough I benchmarked LTO build with mainline and GCC 4.9 and the times
are almost exactly the same on both Firefox and libreoffice. There are some
slowdowns too - the speculative devirtualization issues I plan to fix today,
extra streaming needed, and slowdowns in C++ FE/preprocessor... I will
bechmark last two bit more curefuly ;) But this also means that non-LTO got
slower in 5.0 so I am probably closer to reaching the goal.
> > Ian