search for: bitcode

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

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

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 To: Yung, Douglas Cc: llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu Subject: Re: [LLVMdev] Proposal to add Bitcod...

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

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 `clang -fembed-bitcode -c` does, but for executables. > &g...

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

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

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 ToT? Also, the bitcode "downgrade" is done by : // Use the LLVM 3.2 bitcode writer, instead of the t...

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 makes using the wrapper as a version indicator sort of a non-starter....

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

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 ThinLTO information both in the bitcode-only and native object wrapped case...

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 incorrect code w.r.t. fast math > expectations. > > Should we bump the bitcode versi...

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

...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 oldest version of bitcode that the TOT bitcode reader supports? > > The current policy is that LLVM can read bitcode for any prior version with the same major version number. Thus 3.9svn can read all the way back to 3.0 (and also 3.1/3.2/...). It cannot r...

...t 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 agree this is specific "compared to the usual expected output of as linker", but on the other hand it also has potential for opening cool project that can be built on top of this! If this could be supported in lld without...

...rg>> 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 oldest version of bitcode that the TOT bitcode reader supports? >> >> The current policy is that LLVM can read bitcode for any prior version with the same major version number. Thus 3.9svn can read all the way back to 3.0 (and also 3.1/3.2/...). It...

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++ means that your program will automatically be linked with libstdc...

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 that shouldn't be tied to ThinLTO at all. Fair warning, I'm not going to...

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 bitcode-only reading/writing support is more complete. In fact, as described in this RFC, I d...

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