[llvm-dev] Getting Object Files During LTO

[Bill Wendling via llvm-dev]

On Fri, Aug 10, 2018 at 2:14 PM Teresa Johnson <tejohnson at google.com> wrote:

> On Mon, Aug 6, 2018 at 5:24 PM Quentin Colombet <
> quentin.colombet at gmail.com> wrote:
>
>> I believe the ordering should be deterministic between two runs, but
>> not necessarily in the order of the input files.
>>
>> That said, Steven's answer is probably more interesting to you:
>> > For both thinLTO and fullLTO, there exists APIs to write object file
>> output before sending it to the linker. Depending on which linker you use,
>> linker might provide you with different options.
>>
>
> (Sorry for the slow reply, just back from vacation). Quentin and Steven's
> answers are correct. For the gold linker, you can use
> -Wl,-plugin-opt=save-temps to get the bitcode at various stages of LTO for
> both Thin and regular LTO. For regular LTO the output files will be at the
> output file path, and for ThinLTO there will be a set for each input
> bitcode module, at the input file's path. They end in .bc and the suffixes
> include the name of the phase (i.e. "preopt.bc" for the files at the start
> of LTO.
>
> Okay, thanks. I'll see if I can work around the issue with these options.


>
>> 2018-08-06 16:52 GMT-07:00 Bill Wendling <isanbard at gmail.com>:
>> > On Mon, Aug 6, 2018 at 4:30 PM Quentin Colombet <
>> quentin.colombet at gmail.com>
>> > wrote:
>> >>
>> >> Hi Bill,
>> >>
>> >>
>> >> 2018-08-06 16:13 GMT-07:00 Bill Wendling via llvm-dev
>> >> <llvm-dev at lists.llvm.org>:
>> >> > Is there a way to get object files from the LTO step before the
>> linker
>> >> > performs the final link phase? What I'd like to do is given these
>> >> > bitcode
>> >> > files:
>> >> >
>> >> >   a.lto.o, b.lto.o, c.lto.o
>> >> >
>> >> > run LTO on them and get out the object files:
>> >> >
>> >> >   a.o, b.o, c.o
>> >> >
>> >> > (These .o files hold the code that is sent directly to the final link
>> >> > phase.)
>> >> >
>> >> > If there doesn't currently exist a way, is such a thing possible?
>> >>
>> >> I don't think that's possible, because basically the LTO pipeline will
>> >> put all the input files into one module and we have no way to track
>> >> back what came from what, nor it made much sense after LTO does
>> >> inlining and such.
>> >> That said, for thin-LTO we may still have some of the information
>> around.
>> >>
>> >> + Teresa, she should know.
>> >>
>> > That's what I feared might be the answer. Another question then, would
>> the
>> > function ordering be deterministic? I.e., if a.o had functions "foo",
>> "bar",
>> > and "baz", and b.o had functions "mux", "nux", and bork", would the
>> function
>> > order before it went off to the final link phase be:
>> >
>> >   foo, bar, baz, mux, nux, bork
>> >
>> > (This assumes that none of those functions were inlined or otherwise
>> > deleted.)
>> >
>> > -bw
>>
>
>
> --
> Teresa Johnson |  Software Engineer |  tejohnson at google.com |
> 408-460-2413 <(408)%20460-2413>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180810/eec1f7f9/attachment.html>