Hi Michael, On 19 June 2012 10:55, Michael Meeks <michael.me...@suse.com> wrote: >> I also got an internal compiler error somewhere. > > Yep, so we should file those bugs I suppoe.
For me, to file a bug is almost like to fix a bug for non-developer. And it works with newer gcc anyway. >> Here are few differences in size (not stripped): LTO / not-LTO >> total size of workdir/*/LinkTarget/Library: 290M / 304M > > Goodness - an un-stripped library is of a random size; highly affected > by debuginfo / symbol tables etc. IMHO it is only worth comparing > stripped library sizes; can you easily generate those ? :-) Sure. It's 189M vs. 204M in total. libmergedlo.so 36M / 41M ... libcuilo.so 3.9M / 3.8M is slightly bigger ... nothing more really interesting. I guess -Os would behave similar. >> so sometimes is creates bigger libraries. > > That is interesting; so - Jan - how well does LTO cope with -Os vs. -O2 > etc. and/or Matus - what compile flags are we using ? It's quite random. For me it's -O2 on 64bit system. But we are using -Os on 32bit linux platform. >> Maybe it's not all about the size ? > > :-) well; we want to be smaller of course. Potentially getting more > code inside the libmerged perimiter helps - and potentially better > visibility markup so that the LTO can know that a given function is not > used outside of that libmerged is useful. So far we have only a markup > that says "used outside of un-merged library", really we need to split > that into two types of markup that distinguish whether it is used > outside of libmerged or not (I think). Hmm, this does not seem to be doable quickly. But maybe it's easy and possible to file an easy hack ? > Thanks ! this was a great GSOC project :-) Yep, thanks. Best, Matus _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice