[Interest] Qt 5 LTO build on OS X 10.9 (and earlier)

Thiago Macieira thiago.macieira at intel.com
Sat Sep 12 17:24:14 CEST 2015


On Saturday 12 September 2015 15:13:35 René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > Because we're talking about LTCG, which implies the compiler is run at the
> > linking stage.
> 
> In any case it (clang) doesn't show up in the process list. Also, from what
> I understand clang stores some intermediate LLVM byte-code representation
> (probably the same language-agnostic code that's used by the llvm backend.
> I'm not sure if from there on one can still speak in terms of "invoking the
> compiler" but then that might be splitting hairs.

LTO operates in two steps:
 - the "compilation" is only a parsing to intermediate language (LLVM bitcode 
   for Clang, GIMPLE for GCC)
 - the "linking" transforms the intermediate language into machine code

> > It wouldn't show in ld's arguments. But it shows in the g++ arguments that
> > will eventually run ld. ltcg.prf adds the compiler flags to QMAKE_LFLAGS.
> 
> It also shows in the argument when ld is invoked through clang++ . Still,
> the command doing the heavy lifting is ld, and it seems inefficient if that
> same command doesn't also generate/collect the debug info. There's no
> noticeable delay before or after ld is run (and some link commands are
> heavy and lengthy enough that I'd expect the collection of debug info to
> take a noticeable time if done before or after the optimisation+link
> operation).
> Anyway, I'd better ask about this on an llvm ML.

Make a direct test by running clang manually.

It's possible they think "no one will debug LTO code" and haven't implemented 
the feature.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Interest mailing list