search for: bitcoded

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

Sorry if I was unclear. There are currently no “known incompatibilities” that I am aware of, although I fully admit to not being an expert on the topic. The idea is that we add versioning information to the bitcode so that if an issue were discovered, it could be easily detected and dealt with. Douglas Yung From: Bob Wilson [mailto:bob.wilson at apple.com] Sent: Friday, September 26, 2014 16:39

Hi, TL;DR r317488 changed the way fast math flags are laid out in the bitcode and anyone compiling a pre-llvm-6.0 bitcode with llvm-6.0 will lose all the optimizations guarded by isFast and a pre-llvm-6.0 compiler compiling a llvm-6.0 bitcode will potentially generate incorrect code w.r.t. fast math expectations. Should we bump the bitcode version because of that and have the autoupgrader

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

Hi, We would like to add a version number to the bitcode wrapper. This feature would allow easier identification of what compiler produced the bitcode so that known incompatibilities with LTO compilation could be detected. Roughly speaking, this version number would consist of the major, minor and optionally the patch version of the compiler used to produce the bitcode. The version information

As I understand it, the bitcode compatibility promise doesn't extend as far as debug info metadata (happy to be wrong here!). I think we have a usecase where need to guarantee that debug information from any two arbitrary bitcode files going into an LTO link will result in the expected/correct debug information going into the resulting ELF file; unless we can be sure that this will always

Thanks Steve and Mehdi for the explanation. Steve, I am a little be confused by looking at the code in https://android.googlesource.com/platform/frameworks/compile/libbcc/+/master/bcinfo/BitReader_3_0/BitcodeReader.cpp. Looks like the BitcodeReader do some translation while reading the bitcode. If LLVM ToT can read the bitcode of LLVM 3.0, while can't we just use the bitcode reader in LLVM

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

> Reading the bitcode reader while working on another issues I found > that we already have a version in the bitcode itself (not the darwin > wrapper) and it is used! It is stored with the > bitc::MODULE_CODE_VERSION. It is used to select relative ids, which > impacts the entire bitcode, and so it makes sense to be based on a > version. > > If we ever have a new feature

As discussed in the high-level ThinLTO RFC ( http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/086211.html), we would like to add support for native object wrapped bitcode and ThinLTO information. Based on comments on the mailing list, I am adding support for ThinLTO in both normal bitcode files, as well as native-object wrapped bitcode. The following RFC describes the planned file format of

2018-02-08 17:34 GMT-08:00 Quentin Colombet via llvm-dev < llvm-dev at lists.llvm.org>: > Hi, > > TL;DR > r317488 changed the way fast math flags are laid out in the bitcode and > anyone compiling a pre-llvm-6.0 bitcode with llvm-6.0 will lose all the > optimizations guarded by isFast and a pre-llvm-6.0 compiler compiling a > llvm-6.0 bitcode will potentially generate

Hi, afaics in manuals the llvm-{link,ld} tools only can merge bitcode files into one bigger piece which looks like a static-linking from the c/c++ world. i'm wondering is it any possibility to link bitcode elements dynamically in the same way as e.g. c#/msil assemblies? static linking into one executable looks horrible - any change in library used in project forces relinking of everything.

> On Aug 2, 2016, at 8:38 PM, Stephen Hines via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Hongbin, > > On Tue, Aug 2, 2016 at 8:26 PM, Hongbin Zheng <etherzhhb at gmail.com <mailto:etherzhhb at gmail.com>> wrote: > Hi Steve, > > Several people told me that LLVM TOT bcreader can read odder version of bitcode without any problem. Do you know the

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

> On Aug 2, 2016, at 8:49 PM, Stephen Hines <srhines at google.com> wrote: > > > > On Tue, Aug 2, 2016 at 8:44 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Aug 2, 2016, at 8:38 PM, Stephen Hines via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>

Hi, > thank for your answer. Is there any document/tutorial about linking > bytecode file with libstdc++ avaiable ? first you need to compile the bitcode to assembler using llc. For example: llc bitcode.bc This produces bitcode.s. Turn this into a executable using: llvm-g++ -o bitcode bitcode.s or g++ -o bitcode bitcode.s It doesn't matter which g++ you use here. Using g++

Alex already made what I consider to be the most relevant point. I would suggest removing the unwanted functionality and asking again. From my perspective, native wrapped bitcode is only interesting (and thus worth reviewing and/or talking about) once the native bitcode version is in tree and functional. Frankly, I consider the native wrapped bitcode to be an entirely orthogonal proposal

Hi Alex, After outlining some of the rationale for using native-wrapped, there were a couple of responses that indicated native-wrapped support was reasonable, but they preferred to see bitcode-only first (Phillip and Rafael). This is essentially what this proposal and the patches do - I've implemented some of the basic support for looking for and parsing the native-wrapped sections, but the

I am proposing to add an option to llvm-link allow it to get a list of input bitcode file names from a file. The reason is that there is a limitation for command line length which limits the number of input bitcode files that can be passed to llvm-link. By adding this option we can bypass such limitation. The name of the option can be discussed. My initial proposal would be -input-file-list.