Bill Wendling via llvm-dev
2018-Aug-06 23:52 UTC
[llvm-dev] Getting Object Files During LTO
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 thefunction 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180806/f7d805db/attachment-0001.html>
Quentin Colombet via llvm-dev
2018-Aug-07 00:24 UTC
[llvm-dev] Getting Object Files During LTO
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.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 via llvm-dev
2018-Aug-10 21:14 UTC
[llvm-dev] Getting Object Files During LTO
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.> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180810/c3db30b7/attachment.html>