Re: Skipping assembler when producing slim LTO files

[Jan Hubicka <hubicka at ucw dot cz>]

> > On Wed, Sep 24, 2014 at 7:47 AM, Andi Kleen <andi@firstfloor.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
http://hubicka.blogspot.ca/2014/09/linktime-optimization-in-gcc-part-3.html
and firefox
http://hubicka.blogspot.ca/2014/04/linktime-optimization-in-gcc-2-firefox.html

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

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

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.

Honza
> 
> Honza
> > 
> > Ian