search for: bitcodes

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

...s target info attached, so it's a matter of picking some convenient place to keep that info. Initially only Darwin would do this, but it would be a step up from the current explicit triple check. The wrapper has a standard header, same as the current header: - Magic - Version - BitcodeOffset - BitcodeSize The target can supply additional data to put after the header (and before the actual bitcode starts). Darwin would supply the CPUType field like it does now. This is 100% compatible with what exists today, but will be easy to extend for (ahem) other vendors who want wrappers. Any vendor who su...

...lockID=21 ...> </THINLTO_MODULE_STRTAB_BLOCK> <THINLTO_FUNCTION_SUMMARY_BLOCK BlockID=22 ...> </THINLTO_FUNCTION_SUMMARY_BLOCK> </THINLTO_BLOCK> </MODULE_BLOCK> These block IDs are defined along with other LLVM bitcode IDs in include/llvm/Bitcode/LLVMBitCodes.h: namespace llvm { namespace bitc { // The only top-level block type defined is for a module. enum BlockIDs { // Blocks MODULE_BLOCK_ID = FIRST_APPLICATION_BLOCKID, // Module sub-block id's ... THINLTO_BLOCK_ID, // ThinLTO sub-block id's. THINLTO_...

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

...ynamically 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. i've found a thread[*] in archive but it only describes a new linker tool without virtual machine support for loading bitcodes in runtime. so, is there any plans to develop so called dynamic bitcode linking or there's another solution for this problem? [*] http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-December/046055.html BR, Paweł.

> 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

...LOCK> > > <THINLTO_FUNCTION_SUMMARY_BLOCK BlockID=22 ...> > > </THINLTO_FUNCTION_SUMMARY_BLOCK> > > </THINLTO_BLOCK> > > </MODULE_BLOCK> > > These block IDs are defined along with other LLVM bitcode IDs in > include/llvm/Bitcode/LLVMBitCodes.h: > > namespace llvm { > > namespace bitc { > > // The only top-level block type defined is for a module. > > enum BlockIDs { > > // Blocks > > MODULE_BLOCK_ID = FIRST_APPLICATION_BLOCKID, > > // Module sub-block id's > > ....

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.