<div dir="ltr"><div dir="ltr">On Fri, Feb 1, 2019 at 3:03 AM Josef Eisl <<a href="mailto:josef.eisl@oracle.com">josef.eisl@oracle.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks for sharing your thoughts!<br>
<br>
On 31/01/2019 20:04, Rui Ueyama wrote:<br>
> That feature is probably too specific to your project. Most projects <br>
> that use LTO are using LTO just because it generates better code. Your <br>
> project is special as your program itself can also interpret LLVM <br>
> bitcode, but that's not the case for most other programs.<br>
<br>
I see that the requirement somewhat specific. On the other hand, the <br>
same feature is for example supported on Darwin via the __bundle <br>
section, so I'd see it more as a feature parity measure than something <br>
that is only of use to our project. (My view might be biased, though ;)<br>
<br>
> I think the option that's closest to the one you are looking for is <br>
> `--plugin-opt=emit-llvm`. That option makes lld to make an output file <br>
> in the bitcode file format (so lld doesn't do LTO if the option is given <br>
> and instead writes a raw bitcode as an output). With that option, I <br>
> don't think it's too hard to embed bitcode file to your executable. Run <br>
> the linker twice, with and without `--plugin-opt=emit-llvm`, and embed <br>
> the generated bitcode file using objcopy.<br>
><br>
> Does that work for you?<br>
><br>
<br>
Sure it does and I fully agree that it is currently possible to get to <br>
the result. Actually, there are many different ways to accomplish it <br>
using combinations of wllvm, gllvm, llvm-link, --plugin-opt=emit-llvm, <br>
objcopy, etc. We are currently using these but my feelings about the <br>
approaches are mixed. I see two downsides.<br>
First, they require modifications to the build scripts. We want to <br>
support a variety of different build systems and make it as easy as <br>
possible for users to compile their projects for Sulong. Running the <br>
linker twice is not easy to accomplish in general, especially if the <br>
source project is not under our control. However, adding a linker flag <br>
is simpler in most cases.<br>
Second, the approaches add new dependencies and their portability is <br>
limited. E.g. what about objcopy on Darwin? Anyway, as mentioned above, <br>
Darwin does support embedding linked bitcode, but then we have two <br>
distinct workflows for Linux and Darwin, which I think is not very user <br>
friendly.<br>
<br>
That all said, I understand that there is some hesitation of bringing <br>
new, non-mainstream features to a project that needs to be stable and <br>
maintainable. Anyhow, the prototype we are currently experimenting with <br>
did no require too much work. It reuses existing code from clang (but <br>
unrelated to clang), which we moved to a common place in llvm. The rest <br>
of the patch is mainly option handling. There is hardly any duplication <br>
of logic. I see it more of an addition to existing functionality (i.e., <br>
to `--plugin-opt=emit-llvm`). All the pieces are already there.<br>
<br>
Whatever the outcome of this RFC is, I guess I need thank you and all <br>
other contributors for providing such a stable and mature platform that <br>
allows us to do these kind of changes easily. Thanks. :)<br></blockquote><div><br></div><div>Sorry for the late reply. I'd like to get an opinion from broader audiences.</div><div><br></div><div> - Does anyone think that it is useful to have a linker option to embed LLVM bitcode to a final exectuable when doing LTO? (Currently, LLVM bitcode is discarded once LTO is done.)</div><div> - If so, could you explain your use case?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
> On Thu, Jan 31, 2019 at 4:18 AM Josef Eisl <<a href="mailto:josef.eisl@oracle.com" target="_blank">josef.eisl@oracle.com</a> <br>
> <mailto:<a href="mailto:josef.eisl@oracle.com" target="_blank">josef.eisl@oracle.com</a>>> wrote:<br>
> <br>
> Thanks for your response!<br>
> <br>
> On 30/01/2019 20:18, Rui Ueyama wrote:<br>
> > Hi Josef,<br>
> ><br>
> > Let me clarify my understanding. Do you want to keep original<br>
> bitcode<br>
> > files in the output executable when doing LTO, so that the resulting<br>
> > executable contains both compiled bitcode (which is in native<br>
> machine<br>
> > instructions) and original bitcode files?<br>
> <br>
> Exactly! Kind of analogous to what `clang -fembed-bitcode -c` does, but<br>
> for executables.<br>
> <br>
> ><br>
> > Did you try embedding bitcode files into existing ELF files using<br>
> > objcopy or linker option `--format=binary`?<br>
> <br>
> Yes, that is the alternative. However, having support in the linker for<br>
> that would require less tweaking of exiting build systems. Adding an<br>
> option to CFLAGS/LDFLAGS would then be sufficient.<br>
> <br>
> ><br>
> > On Mon, Jan 28, 2019 at 6:41 AM Josef Eisl via llvm-dev<br>
> > <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>>><br>
> wrote:<br>
> ><br>
> > Hi everybody!<br>
> ><br>
> > I'm Josef and I'm working at Oracle Labs on Sulong [1,2], the<br>
> LLVM IR<br>
> > execution engine in GraalVM [3]. In addition to executing<br>
> bare bitcode<br>
> > files, Sulong also accepts ELF files with embedded bitcode<br>
> sections.<br>
> > Therefore, it would be great if LLD in (Full)LTO mode would<br>
> support<br>
> > embedding bitcode sections to the resulting object file. Is that<br>
> > something that would be considered useful and worth contributing?<br>
> ><br>
> > Thanks,<br>
> > Josef<br>
> ><br>
> <br>
<br>
</blockquote></div></div>