similar to: [RFC] Embedding Bitcode in Object Files

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.

> 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 everyone I am still in the process of upstreaming some improvements to the embed bitcode option. If you want more background, you can read the previous RFC (http://lists.llvm.org/pipermail/llvm-dev/2016-February/094851.html <http://lists.llvm.org/pipermail/llvm-dev/2016-February/094851.html>). This is part II of the discussion. Current Status: A basic version of -fembed-bitcode option

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

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

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).

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: > > > >>

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

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

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

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 :)

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

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

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

Hi all, I'd like to propose changes to how we do promotion of global values in ThinLTO. The goal here is to make it possible to pre-compile parts of the translation unit to native code at compile time. For example, if we know that: 1) A function is a leaf function, so it will never import any other functions, and 2) The function's instruction count falls above a threshold specified at

On Wed, Apr 6, 2016 at 4:53 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Apr 6, 2016, at 4:41 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > Hi all, > > I'd like to propose changes to how we do promotion of global values in > ThinLTO. The goal here is to make it possible to pre-compile parts of the > translation unit to native code at

> On Apr 6, 2016, at 9:40 PM, Teresa Johnson <tejohnson at google.com> wrote: > > > > On Wed, Apr 6, 2016 at 5:13 PM, Peter Collingbourne <peter at pcc.me.uk <mailto:peter at pcc.me.uk>> wrote: > > > On Wed, Apr 6, 2016 at 4:53 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Apr 6,

On Tue, May 3, 2016 at 9:01 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Apr 6, 2016, at 4:41 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > Hi all, > > I'd like to propose changes to how we do promotion of global values in > ThinLTO. The goal here is to make it possible to pre-compile parts of the > translation unit to native code at

On Tue, May 3, 2016 at 10:04 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On May 3, 2016, at 10:01 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > > > On Tue, May 3, 2016 at 9:01 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Apr 6, 2016, at 4:41 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >>

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