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 _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
