[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Link-time optimization in debian packages



On Sun, Jun 05, 2011 at 01:18:43PM +0200, Emil Langrock wrote:
> Hi,
> 
> I have currently the problem that I have to use large, computing intensive 
> applications [1,2]. These are usually implemented in many source files. I used 
> in the past pseudo c files which include all other c files [3]. Of course, 
> this is a hack and don't work in many situation due to conflicting local 
> symbols.
> 
> I played around a little bit with GCC's LTO [4]. It is really impressive for 
> this kind of applications. I had a size reduction and speed increase with the 
> tested applications. Of course, it was just a small testset and not really 
> scientific.
> 
> Link time-optimization exchanges the meaning of flags slightly [5]. It is 
> currently necessary to provide the optimization related flags from 
> CFLAGS/CXXFLAGS also in LDFLAGS. Otherwise the LTO will not really to a 
> optimization step.
> 
> I already found some smaller problems related to weird asm usage in some pic 
> library code [6], but I would doubt that this is a big show blocker and will 
> be fixed soon(tm).
> 
> My question is now whether there are already plans to use LTO in Debian 
> packages, any big debian related studies, policies, release goals, ...? It 
> could also be interesting for large projects like Iceweasel, LibreOffice, ... 
> Maybe the KDE Debian Package maintainer have a reason why they don't use 
> KDE4_ENABLE_FINAL --- which would also be an argument against LTO.

On the large projects you are mentioning, LTO is simply not possible to
use at all on gcc 4.6. For instance, the linking phase for Firefox
requires more memory than the address space on 32-bits machines permit,
which means we'd need a) buildds with a lot of RAM b) to cross compile
32-bits code with 64-bits toolchains.

gcc 4.7 should be better, though.

Mike


Reply to: