search for: femb

...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 is upstreamed and functioning. You can use -fembed-bitcode={off, all, bitcode, marker} option to control what gets embedded in the final object file output: off: default, nothing gets embedded. all: optimized bitcode and command line options gets embedded in the object file. bitcod...

...archive which is embedded in the output. The archive also contains all the information that is needed to rebuild the linked binary. All compilation and linking stage can be replayed to generated the final binary. There are mainly two parts we would like to upstream first: 1. Clang Driver: Adding -fembed-bitcode option. When this new option is used, it will split the compilation into 2 stages. The first stage runs the frontend and all the optimization passes, and the second stage embeds the bitcode from the first stage then runs the CodeGen passes. There is also a -fembed-bitcode-marker option t...

...-line including the -fdebug-prefix-map argument gets stored in the output too, then you still have a problem. I don't think we need any path in the command line section. We only record the command-line options that will affect CodeGen. See my example in one of the preview reply: > $ clang -fembed-bitcode -O0 test.c -c -### > "clang" "-cc1" (...lots of options...) "-o" "test.bc" "-x" "c" "test.c" <--- First stage > "clang" "-cc1" "-triple" "x86_64-apple-macosx10.11.0" &...

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

...ection "llvm.metadata" >> @llvm.compiler.used = appending global [1 x i8*] [i8* bitcast (void ()* >> @foo to i8*)], section "llvm.metadata" >> >> >> # Compile IR -> Obj directly. >> clang -cc1 -triple x86_64-apple-macosx10.13.0 -emit-obj -fembed- >> bitcode=all -x ir test.ll -o test_ll.o >> >> # Compile IR -> BC -> Obj. >> clang -cc1 -triple x86_64-apple-macosx10.13.0 -emit-llvm-bc -fblocks - >> fencode-extended-block-signature -x ir test.ll -o test.bc >> clang -cc1 -triple x86_64-apple-macosx1...

...obal [1 x i8*] [i8* bitcast (void ()* @foo to i8*)], section "llvm.metadata" @llvm.compiler.used = appending global [1 x i8*] [i8* bitcast (void ()* @foo to i8*)], section "llvm.metadata" # Compile IR -> Obj directly. clang -cc1 -triple x86_64-apple-macosx10.13.0 -emit-obj -fembed-bitcode=all -x ir test.ll -o test_ll.o # Compile IR -> BC -> Obj. clang -cc1 -triple x86_64-apple-macosx10.13.0 -emit-llvm-bc -fblocks -fencode-extended-block-signature -x ir test.ll -o test.bc clang -cc1 -triple x86_64-apple-macosx10.13.0 -emit-obj -fembed-bitcode=all -x ir test.bc -o te...

...ng these flags with LTO because they are likely to be dropped in the process. That is my next thing to do if someone reviews my patch and agrees that is right thing to do. > > 2. Assembly input handling: > This is a workaround to allow source code written in assembly to work with "-fembed-bitcode" options. When compiling assembly source code with "-fembed-bitcode", clang-as creates an empty section "__LLVM, __asm" in the object file. That is just a way to distinguish object files compiled from assembly source from those compiled from higher level source co...

...optimization passes, as well as the command line options needed for >> later compiling that IR to the same native object it was compiled to >> originally (with the same compiler). >> >> Here's what I don't understand: say you have a.o and b.o compiled with >> -fembed-bitcode=all. They are linked into a binary called my_binary. How do >> you re-create the corresponding IR for modules a and b (let's call them >> a.bc and b.bc), and their corresponding command lines? From what I can >> tell, the linker just concatenates the IR for a and b i...

...e passing it to LLVM's optimization passes, as well as the command line options needed for later compiling that IR to the same native object it was compiled to originally (with the same compiler). >> >> Here's what I don't understand: say you have a.o and b.o compiled with -fembed-bitcode=all. They are linked into a binary called my_binary. How do you re-create the corresponding IR for modules a and b (let's call them a.bc and b.bc), and their corresponding command lines? From what I can tell, the linker just concatenates the IR for a and b in my_binary's .llvmbc,...

...also >> contains all the information that is needed to rebuild the linked binary. All >> compilation and linking stage can be replayed to generated the final binary. >> >> There are mainly two parts we would like to upstream first: >> 1. Clang Driver: >> Adding -fembed-bitcode option. When this new option is used, it will split the >> compilation into 2 stages. The first stage runs the frontend and all the >> optimization passes, and the second stage embeds the bitcode from the first >> stage then runs the CodeGen passes. There is also a -fem...

...On Fri, Feb 5, 2016 at 6:06 PM, Steven Wu <stevenwu at apple.com<mailto:stevenwu at apple.com>> wrote: I don't think we need any path in the command line section. We only record the command-line options that will affect CodeGen. See my example in one of the preview reply: $ clang -fembed-bitcode -O0 test.c -c -### "clang" "-cc1" (...lots of options...) "-o" "test.bc" "-x" "c" "test.c" <--- First stage "clang" "-cc1" "-triple" "x86_64-apple-macosx10.11.0" "-emit...

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). Furthermore, I do need the final output to contain bitcode for all files used. So, my question...

...On Fri, Feb 5, 2016 at 6:06 PM, Steven Wu <stevenwu at apple.com<mailto:stevenwu at apple.com>> wrote: I don't think we need any path in the command line section. We only record the command-line options that will affect CodeGen. See my example in one of the preview reply: $ clang -fembed-bitcode -O0 test.c -c -### "clang" "-cc1" (...lots of options...) "-o" "test.bc" "-x" "c" "test.c" <--- First stage "clang" "-cc1" "-triple" "x86_64-apple-macosx10.11.0" "-emit...

...y 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. > > Did you try embedding bitcode files into existing ELF files using > objcopy or linker option `--format=binary`? Yes, that is the alternative. However, having support in the linker for that would require less tweaking of exiting build syste...

.../RangeReplaceableCollection+IndexSet.bc \ <mypath>/DreamPreviewHeaderReusableView.bc \ <mypath>/Rendering.bc ######################## ######################## xcrun \ --sdk iphoneos \ <mypath>/Xcode_9.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ \ -fembed-bitcode \ <mypath>/iOS_APP.bc \ -arch arm64 \ -O0 \ -c \ -o <mypath>/iOS_APP.bc.o ######################## ######################## llvm-dwarfdump -verbose -verify small.o > small.o.dwarfdump Any insights would be appreciated. Input bitcode files are attached. Thanks, Jack -----...

...riginal 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. >> >> > >> > Did you try embedding bitcode files into existing ELF files using >> > objcopy or linker option `--format=binary`? >> >> Yes, that is the alternative. However, having support in the linker fo...

Pavel Punsky <Pavel.Punsky at oovoo.com> wrote: > 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. You cannot use bitcode with assembly. It may be possible if someone manually translates the asm into LLVM IR and then figures out how to embed it directly in a .S file, but that seems like a ridiculous amount o...

.../RangeReplaceableCollection+IndexSet.bc \ <mypath>/DreamPreviewHeaderReusableView.bc \ <mypath>/Rendering.bc ######################## ######################## xcrun \ --sdk iphoneos \ <mypath>/Xcode_9.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ \ -fembed-bitcode \ <mypath>/iOS_APP.bc \ -arch arm64 \ -O0 \ -c \ -o <mypath>/iOS_APP.bc.o ######################## ######################## llvm-dwarfdump -verbose -verify small.o > small.o.dwarfdump Any insights would be appreciated. Input bitcode files are attached. Thanks, Jack ____...

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

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 bitcode compatibility tests but most of them only covers the bitcode reader. But the compatibility issue goes way beyond that. It is hard to keep the semantics of the original program while the to...