search for: llvmbc

Hi Mircea, If you use an ordinary linker that concatenates .llvmbc sections, you can use this code to get the size of each bitcode module. As far as I know, there's no clean way to separate the .llvmcmd sections without making assumptions about what options were used. // Given a bitcode file followed by garbage, get the size of the actual // bitcode. This onl...

...clude in the payload the name of the module, too; maybe compress > it, too). Same for the .llvmcmd case. > > On Thu, Aug 27, 2020 at 6:57 PM Sean Bartell <smbarte2 at illinois.edu> > wrote: > >> Hi Mircea, >> >> If you use an ordinary linker that concatenates .llvmbc sections, you can >> use this code to get the size of each bitcode module. As far as I know, >> there's no clean way to separate the .llvmcmd sections without making >> assumptions about what options were used. >> >> // Given a bitcode file followed by garbage, get...

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 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > &gt...

...mation, where it can be used by individual ThinLTO backends. In the future, we could also consider representing importing summaries as metadata. That would also make the summary loading process very straightforward. Alternatives 1) We could use a native object file, with one section named ".llvmbc" containing the summary module with the vtables and CFI metadata, and another section ".llvmbc.thin" containing "everything else". This would be my preferred option, as it would make things even simpler. For example, the linker could handle the top-level sections as it read...

...circular dependence. > > > > > > b. ELF wrapper generation support: > > > > Implement ELF wrapped bitcode writer. In order to more easily interact > > with tools such as $AR, $NM, and “$LD -r” we plan to emit the phase-1 > > bitcode wrapped in ELF via the .llvmbc section, along with a symbol > > table. The goal is both to interact with these tools without requiring > > a plugin, and also to avoid doing partial LTO/ThinLTO across files > > linked with “$LD -r” (i.e. the resulting object file should still > > contain ELF-wrapped bitcod...

...; >> > b. ELF wrapper generation support: > >> > > >> > Implement ELF wrapped bitcode writer. In order to more easily interact > >> > with tools such as $AR, $NM, and “$LD -r” we plan to emit the phase-1 > >> > bitcode wrapped in ELF via the .llvmbc section, along with a symbol > >> > table. The goal is both to interact with these tools without requiring > >> > a plugin, and also to avoid doing partial LTO/ThinLTO across files > >> > linked with “$LD -r” (i.e. the resulting object file should still > >...

...> > > >> >> > Implement ELF wrapped bitcode writer. In order to more easily > >> >> > interact > >> >> > with tools such as $AR, $NM, and “$LD -r” we plan to emit the > phase-1 > >> >> > bitcode wrapped in ELF via the .llvmbc section, along with a symbol > >> >> > table. The goal is both to interact with these tools without > >> >> > requiring > >> >> > a plugin, and also to avoid doing partial LTO/ThinLTO across files > >> >> > linked with “$LD -r”...

...> Implement ELF wrapped bitcode writer. In order to more easily >>> >> >> > interact >>> >> >> > with tools such as $AR, $NM, and “$LD -r” we plan to emit the >>> phase-1 >>> >> >> > bitcode wrapped in ELF via the .llvmbc section, along with a >>> symbol >>> >> >> > table. The goal is both to interact with these tools without >>> >> >> > requiring >>> >> >> > a plugin, and also to avoid doing partial LTO/ThinLTO across >>> file...

...pped bitcode writer. In order to more easily >>> >> >> > interact >>> >> >> > with tools such as $AR, $NM, and “$LD -r” we plan to emit the >>> >> >> > phase-1 >>> >> >> > bitcode wrapped in ELF via the .llvmbc section, along with a >>> >> >> > symbol >>> >> >> > table. The goal is both to interact with these tools without >>> >> >> > requiring >>> >> >> > a plugin, and also to avoid doing partial LTO/ThinLTO a...

...inLTO for native-wrapped bitcode intermediate files. The discussion here uses ELF as an example, but should also apply to other formats such as COFF and Mach-O [1]. Native-wrapped bitcode There is already support in LLVM for reading native-wrapped bitcode, where the bitcode is contained within an .llvmbc section. For ThinLTO, unlike in the earlier bitcode-only case, the ThinLTO information is not nested within the MODULE_BLOCK contained within the .llvmbc section. Instead, the native object will contain a symbol table, and special sections holding the additional ThinLTO information. These sections...

...tively. Only LTOCodeGenerator has a dependence on IPO, removing the circular dependence. b. ELF wrapper generation support: Implement ELF wrapped bitcode writer. In order to more easily interact with tools such as $AR, $NM, and “$LD -r” we plan to emit the phase-1 bitcode wrapped in ELF via the .llvmbc section, along with a symbol table. The goal is both to interact with these tools without requiring a plugin, and also to avoid doing partial LTO/ThinLTO across files linked with “$LD -r” (i.e. the resulting object file should still contain ELF-wrapped bitcode to enable ThinLTO at the full link ste...

...e easily >> >>> >> >> > interact >> >>> >> >> > with tools such as $AR, $NM, and “$LD -r” we plan to emit the >> >>> >> >> > phase-1 >> >>> >> >> > bitcode wrapped in ELF via the .llvmbc section, along with a >> >>> >> >> > symbol >> >>> >> >> > table. The goal is both to interact with these tools without >> >>> >> >> > requiring >> >>> >> >> > a plugin, and also...

...n. When one does an install, everything that gets installed should be under the $(prefix) variable somewhere. This is almost true today, except for the things that are installed into $(bytecode_libdir). So, to clear up the inconsistency, I would like to redefine: $(bytecode_libdir) = $(libdir)/llvmbc This would put bytecode libraries into a separate directory under the normal (native) "lib" directory during install. Note that the bytecode libraries MUST be located in a separate directory to eliminate confusion with the regular system librarys. For example, say we configure with -...

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

The following code causes opt to not terminate! With TOT this morning, and of a week ago: clang foo.c and clang -O1 foo.c work fine. clang -O2 foo.c and clang -O3 foo.c do not terminate. (At least after 10 minutes) If I generate the bit code (clang-cc -emit-llvmbc) and then run: opt -O3 foo.bc it does not terminate. //foo.c int get_id(int); typedef short short2 __attribute__ ((vector_size (2))); union _X { short2 s; int i; }; typedef union _X X; inline short2 as_short2(int x) { X result; result.i = x;...

...t; >>> >> >> > with tools such as $AR, $NM, and “$LD -r” we plan to emit >>>> >>> >> >> > the >>>> >>> >> >> > phase-1 >>>> >>> >> >> > bitcode wrapped in ELF via the .llvmbc section, along with a >>>> >>> >> >> > symbol >>>> >>> >> >> > table. The goal is both to interact with these tools without >>>> >>> >> >> > requiring >>>> >>> >> &...

...t contains a large number of test binaries 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...

...t;> > with tools such as $AR, $NM, and “$LD -r” we plan to emit >> >>>> >>> >> >> > the >> >>>> >>> >> >> > phase-1 >> >>>> >>> >> >> > bitcode wrapped in ELF via the .llvmbc section, along >> >>>> >>> >> >> > with a >> >>>> >>> >> >> > symbol >> >>>> >>> >> >> > table. The goal is both to interact with these tools >> >>>> >&...

...t;> > with tools such as $AR, $NM, and “$LD -r” we plan to emit >> >>>> >>> >> >> > the >> >>>> >>> >> >> > phase-1 >> >>>> >>> >> >> > bitcode wrapped in ELF via the .llvmbc section, along >> with a >> >>>> >>> >> >> > symbol >> >>>> >>> >> >> > table. The goal is both to interact with these tools >> without >> >>>> >>> >> >> > requi...

...ct wrapped bitcode writer. The main goal is to more easily interact with existing native tools such as $AR, $NM, “$LD -r”, $OBJCOPY, and $RANLIB, without requiring the build system to find and pass the plugin as an option. We plan to emit the phase-1 bitcode wrapped in native object format via the .llvmbc section, along with a symbol table. We will implement ELF first, but subsequently extend support to COFF and Mach-O. Additionally, we also want to avoid doing partial LTO/ThinLTO across files linked with “$LD -r” (i.e. the resulting object file should still contain native object-wrapped bitcode to...