search for: __llvm

...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 is if it is possible to add the `__LLVM,__bitcode` section later to the MachO object file. I tried to archive the bitcode using `xar` and run `llvm-objcopy main.o --add-section=__LLV...

.... Linker can still check the presence of the section to provide feedback if any of the object files participated in the linking is missing bitcode in a full bitcode build. 2. Bitcode Embedding: Several special sections are used by bitcode to mark the presence of the bitcode in the MachO file. "__LLVM, __bitcode" is used to store the optimized bitcode in the object file. It can have an 1-byte size as a marker to provide diagnostics in debug build. "__LLVM, __cmdline" is used to store the clang command-line options. There are few options that are not reflected in the bitcode that...

...-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 test_bc.o # Extract and disassemble embedded bitcode from both scenarios. segedit test_bc.o -extract __LLVM __bitcode bc_bc.bc segedit test_ll.o -extract __LLVM __bitcode ll_bc.bc llvm-dis bc_bc.bc llvm-dis ll_bc.bc # Diff both IR files to show that only bc_bc.ll contains "llvm.compiler.used" diff bc_bc.ll ll_bc.ll - Dennis Frett -------------- next part -------------- A non-text attachment w...

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. Thanks Steven > On Feb 3, 2016, at 10:48 A...

...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 test_bc.o >> >> # Extract and disassemble embedded bitcode from both scenarios. >> segedit test_bc.o -extract __LLVM __bitcode bc_bc.bc >> segedit test_ll.o -extract __LLVM __bitcode ll_bc.bc >> llvm-dis bc_bc.bc >> llvm-dis ll_bc.bc >> >> # Diff both IR files to show that only bc_bc.ll contains >> "llvm.compiler.used" >> diff bc_bc.ll ll_bc.ll >> >&g...

...aries based on common libraries). This can be done with a change to the intermediate object file format. We can represent object files as native code containing statically compiled functions and global data in the .text,. data, .rodata (etc.) sections, with an .llvmbc section (or, I suppose, "__LLVM, __bitcode" when targeting Mach-O) containing bitcode for functions to be compiled at link time. In order to make this work, we need to make sure that references from link-time compiled functions to statically compiled functions work correctly in the case where the statically compiled functio...

...ion in "Options.td" as specific group. 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 code but forgot to use "-fembed-bitcode" options. Linker can use this section to diagnose if "-fembed-bitcode" is consistent...

...braries). > > This can be done with a change to the intermediate object file format. We > can represent object files as native code containing statically compiled > functions and global data in the .text,. data, .rodata (etc.) sections, > with an .llvmbc section (or, I suppose, "__LLVM, __bitcode" when targeting > Mach-O) containing bitcode for functions to be compiled at link time. > > > I was wondering why can't the "precompiled" function be embedded in the IR > instead of the bitcode embedded in the object file? > The codegen would still em...

...braries). > > This can be done with a change to the intermediate object file format. We > can represent object files as native code containing statically compiled > functions and global data in the .text,. data, .rodata (etc.) sections, > with an .llvmbc section (or, I suppose, "__LLVM, __bitcode" when targeting > Mach-O) containing bitcode for functions to be compiled at link time. > > In order to make this work, we need to make sure that references from > link-time compiled functions to statically compiled functions work > correctly in the case where the sta...

...mon libraries). >> >> This can be done with a change to the intermediate object file format. We can represent object files as native code containing statically compiled functions and global data in the .text,. data, .rodata (etc.) sections, with an .llvmbc section (or, I suppose, "__LLVM, __bitcode" when targeting Mach-O) containing bitcode for functions to be compiled at link time. >> >> In order to make this work, we need to make sure that references from link-time compiled functions to statically compiled functions work correctly in the case where the staticall...

I've fixed this specific error in r164813. Please let me know if there are more behind it. On Thu, Sep 27, 2012 at 2:16 PM, Sid Manning <sidneym at codeaurora.org> wrote: > > I just updated my llvm sources (revision 164794.) and I see the error, > "overriding non-deleted function" when building with gcc 4.7.0 and passing > -std=c++11. > >

...gt;> This can be done with a change to the intermediate object file format. We >> can represent object files as native code containing statically compiled >> functions and global data in the .text,. data, .rodata (etc.) sections, >> with an .llvmbc section (or, I suppose, "__LLVM, __bitcode" when targeting >> Mach-O) containing bitcode for functions to be compiled at link time. >> >> >> I was wondering why can't the "precompiled" function be embedded in the >> IR instead of the bitcode embedded in the object file? >> Th...

...>>>> >>>> This can be done with a change to the intermediate object file format. We can represent object files as native code containing statically compiled functions and global data in the .text,. data, .rodata (etc.) sections, with an .llvmbc section (or, I suppose, "__LLVM, __bitcode" when targeting Mach-O) containing bitcode for functions to be compiled at link time. >>>> >>>> In order to make this work, we need to make sure that references from link-time compiled functions to statically compiled functions work correctly in the case whe...

I just updated my llvm sources (revision 164794.) and I see the error, "overriding non-deleted function" when building with gcc 4.7.0 and passing -std=c++11. /usr2/sidneym/llvm/tools/install/bin/c++ -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -std=c++11 -fPIC -fvisibility-inlines-hidden -I/local/scratch/llvm-tmp/build/lib/VMCore

...>>> >>>>> This can be done with a change to the intermediate object file format. We can represent object files as native code containing statically compiled functions and global data in the .text,. data, .rodata (etc.) sections, with an .llvmbc section (or, I suppose, "__LLVM, __bitcode" when targeting Mach-O) containing bitcode for functions to be compiled at link time. >>>>> >>>>> In order to make this work, we need to make sure that references from link-time compiled functions to statically compiled functions work correctly in the...

...aries). >>> >>> This can be done with a change to the intermediate object file format. We can represent object files as native code containing statically compiled functions and global data in the .text,. data, .rodata (etc.) sections, with an .llvmbc section (or, I suppose, "__LLVM, __bitcode" when targeting Mach-O) containing bitcode for functions to be compiled at link time. >>> >>> In order to make this work, we need to make sure that references from link-time compiled functions to statically compiled functions work correctly in the case where the s...

...rees 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 code but forgot to use "-fembed-bitcode" options. Linker can use this section to diagnose if "-fembed-bitcode" is consistent...

...;) (in > /home/alex/llvm/Release+__Asserts/lib/Hello.so) > ==5134== by 0x8E33DE3: > llvm::MPPassManager::__runOnModule(llvm::Module&) (in > /home/alex/llvm/Release+__Asserts/bin/opt) > ==5134== by 0x8E3726F: llvm::PassManagerImpl::run(__llvm::Module&) (in > /home/alex/llvm/Release+__Asserts/bin/opt) > ==5134== by 0x8E37385: llvm::PassManager::run(llvm::__Module&) (in > /home/alex/llvm/Release+__Asserts/bin/opt) > ==5134== by 0x41AE4D2: (below main) (libc-start.c:226) >...

> 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 like to replay in > the rebuild. For example, '-O0' option makes us run FastISel during rebuild. > > Without knowing more details of yo...

Hello Duncan, Thank you for your quick answer. I use the standard Makefile from a pass, that is calling Makefile.common. I saw only the make -d option, that "*print lots of debugging information*", as mentioned by LLVM. Using this, valgrind don't tell me extra info. It is a very good idea ti use -g, but where to insert? If I am trying to use clang++, I have to fix a lot of things.