llvm dev - Aug 2018 - Getting Object Files During LTO

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?

-bw
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180806/e57c2f92/attachment.html>

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.

Cheers,
-Quentin
>
> -bw
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

> On Aug 6, 2018, at 4:13 PM, Bill Wendling via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 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
> 
I assume you are asking for thinLTO because the fullLTO will merge all the
bitcode file into one module and there will be only one object file output.
> 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?
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.

Steven
> 
> -bw
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180806/f7d805db/attachment-0001.html>