similar to: [RFC] Embedded bitcode and related upstream (Part II)

Thanks for the feedback! Replies inline. > On Jun 12, 2016, at 11:44 PM, Eric Christopher <echristo at gmail.com> wrote: > > Hi Steven, > > Great to see the commentary and updates here. I've got a few questions about some of this work. It might be nice to see some separate RFCs for a couple of things, but we'll figure that out after you send out patches probably :)

Apple has some internal implemenation for embedding bitcode in the object file that we would like to upstream. It has few changes to clang frontend, including new clang options, clang driver changes and utilities to embed bitcode inside object file. We believe upstreaming these implementations will benefit the people who would like to develop software on Apple platform using open source LLVM. It

Hi Peter It is not currently related because we started the implementation before Thin-LTO gets proposed in the community but our "__LLVM, __bitcode" section is pretty much the same as ".llvmbc" section. Note ".llvmbc" doesn't really follow the section naming convention for MachO objects. I am hoping to unify them during the upstream of the implementation.

This is a silly question, but I am in a situation where I need to build x86 and arm assembly sources for some sources while the rest will be built with C. I do know that just adding `-fembed-bitcode` to a C sources would embed bitcode, but doing the same for the assembly files will not do that (at least, it will add the 1-byte `_LLVM,__asm` section, but not the `__LLVM,__bitcode` section).

We've noticed a difference in the embedded bitcode when compiling human readable IR to an object directly vs first compiling IR to BC and then an object through clang -cc1. If the original IR file contained an "llvm.compiler.used" gv, it will be preserved when compiling IR -> BC -> Obj. When compiling IR -> Obj directly, it will be removed. This difference does not exist

Going from IR <-> BC does not seem to create a difference. IR -> BC -> IR -> BC, either with clang frontent or by using llvm-as and llvm-dis yields identical bc files. I have only been able to reproduce this issue when emitting to an object file. > On 18 Jan 2019, at 18:09, <paul.robinson at sony.com> <paul.robinson at sony.com> wrote: > > > >>

Hi Mircea, If you use an ordinary linker that concatenates .llvmbc sections, you can use this code to get the size of each bitcode module. As far as I know, there's no clean way to separate the .llvmcmd sections without making assumptions about what options were used. // Given a bitcode file followed by garbage, get the size of the actual // bitcode. This only works correctly with some kinds

You should probably pull in some folks who implemented/maintain the feature for Darwin. I guess they aren't linking this info, but only communicating in the object file between tools - maybe they flag these sections (either in the object, or by the linker) as ignored/dropped during linking. That semantic could be implemented in ELF too by marking the sections SHF_IGNORED or something

> On Feb 5, 2016, at 2:14 PM, James Y Knight <jyknight at google.com> wrote: > > On Wed, Feb 3, 2016 at 1:25 PM, Steven Wu via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > "__LLVM, __cmdline" is used to store the clang command-line options. There are > few options that are not reflected in the bitcode that we would

Hi, What is the proper way of enabling bitcode on iOS platform? I pass -fembed-bitcode in CFLAGS but it looks like it does not work on assembly files. Thanks, Pavel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20151019/ab393204/attachment.htm

I don't know whether this is an issue in the current implementation, but I wanted to bring up a potential privacy issue. In embedding the information, care should be taken to avoid embedding any information that contains personally identifiable information. This can certainly occur if paths need to be embedded, as user names, or other private/confidential information may be present in the

Thanks for your response! On 30/01/2019 20:18, Rui Ueyama wrote: > Hi Josef, > > Let me clarify my understanding. Do you want to keep original bitcode > files in the output executable when doing LTO, so that the resulting > executable contains both compiled bitcode (which is in native machine > instructions) and original bitcode files? Exactly! Kind of analogous to what

Hal, No, it is not more of a problem than with DWARF info. DWARF info definitely contains personally identifiable information. However, people usually realize that is the case, and will turn off or strip debug info if they are worried about such issues, or make a specific plan to cleanse that information. You really just want to attempt to eliminate such information to the greatest extent

On Thu, Jan 31, 2019 at 11:05 AM Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > That feature is probably too specific to your project. Most projects that > use LTO are using LTO just because it generates better code. Your project > is special as your program itself can also interpret LLVM bitcode, but > that's not the case for most other programs. > I

I am experiencing an issue combining bitcode files for the purpose of generating the combined bitcodes as a single bitcode file. I would like to have any pointers to help me debug this or maybe it has been seen before and a fix is either being worked on or is done. I am using the Xcode 9.0 compiler. I believe the Swift code is 3.x. I have reproduced this using the tot llvm-link. The input

Hi I am late to the party. Here is my personal take of the topic: * Do you ship software as IR today? What lessons have you learned? Yes. We accept AppStore submission in bitcode (LLVM IR). The core function in clang is upstreamed and you can look up the related code path triggered by -fembed-bitcode option. * Challenges of shipping software as IR Compatibility: We are trying to enhance the

Hi everybody! I'm Josef and I'm working at Oracle Labs on Sulong [1,2], the LLVM IR execution engine in GraalVM [3]. In addition to executing bare bitcode files, Sulong also accepts ELF files with embedded bitcode sections. Therefore, it would be great if LLD in (Full)LTO mode would support embedding bitcode sections to the resulting object file. Is that something that would be

+llvm-dev Can you give a bit of background on what you're trying to address here? After reading through the discussion and seeing that this is a best effort flag, I'm not sure that a function attribute is the best way to describe this. I'm open to being convinced it is, but I'd like to hear a bit more about the use case and get broader visibility on the proposal first.

Hi Sean, > Rafael gave me some of the backstory on this. Basically it is to work around some buggy behavior in the Darwin ar. Adding that on the front of the bitcode file just to get a version doesn't seem > like a very clean thing to do. > > Doug, what other alternatives did you guys consider before settling on this? > > As for #2 above, the non-universality of the wrapper

To be clear, this is a debuging aid only? It's not something required for correctness? I'm somewhat bothered by that because it seems like it would be a useful implementation tool for higher level languages. A couple of thoughts in no particular order: 1) Can we always annotate the call site rather than the function? That removes the unpredictability due to optimization. 2) Calling