search for: module_blocks

...function bodies, etc. > </MODULE_BLOCK> > <STRTAB_BLOCK> > <STRTAB_BLOB blob="foo\0bar\0baz\0"> > </STRTAB_BLOCK> > > > Why is the string table after the module instead of before? > > > Each STRTAB_BLOCK would apply to all preceding MODULE_BLOCKs. This means > that bitcode files can continue to be concatenated with "llvm-cat -b". > > Do you mean "apply to all preceding MODULE_BLOCKs that aren't followed by an intervening STRTAB_BLOCK"? I.e. when bitcode files are concatenated you presumably don't want to...

...0=0 ...> ; name = foo <GLOBALVAR op0=4 ...> ; name = bar <ALIAS op0=8 ...> ; name = baz ; function bodies, etc. </MODULE_BLOCK> <STRTAB_BLOCK> <STRTAB_BLOB blob="foo\0bar\0baz\0"> </STRTAB_BLOCK> Each STRTAB_BLOCK would apply to all preceding MODULE_BLOCKs. This means that bitcode files can continue to be concatenated with "llvm-cat -b". (Normally bitcode files would contain a single string table, which in multi-module bitcode files would be shared between modules.) This *almost* allows us to remove the global (top-level) VST entirely, if...

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

...of type StringTableBuilder which would accumulate strings while writing the bitcode module(s) (and symtab in the future). At the end, the client would call something like BitcodeWriter::writeStrtab() which would write out the string table. > > Each STRTAB_BLOCK would apply to all preceding MODULE_BLOCKs. This means > that bitcode files can continue to be concatenated with "llvm-cat -b". > (Normally bitcode files would contain a single string table, which in > multi-module bitcode files would be shared between modules.) > > This *almost* allows us to remove the global (top-...

...to the string table, and the symbol table builder may also need to add mangled names. Trying to impose an ordering on all of those components doesn't seem worth it in my opinion. Peter > > — > Mehdi > > > > >> >> Each STRTAB_BLOCK would apply to all preceding MODULE_BLOCKs. This means >> that bitcode files can continue to be concatenated with "llvm-cat -b". >> (Normally bitcode files would contain a single string table, which in >> multi-module bitcode files would be shared between modules.) >> >> This *almost* allows us to rem...

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

Hi all, I updated the patches to remove the native object wrapper format. As suggested we will work on getting the ThinLTO framework in place using bitcode first, and then work on adding the native object support. As noted in this RFC and in the associated patch D11722, for now I have empty ThinLTO blocks with no records, since I wanted to get feedback on the overall block design first. The RFC

Hi, I currently write a tool to parse the LLVM bytecode file (.bc file). So I have some very basic questions: - First, about the Abbreviation ID ( "0"=END_BLOCK, "1"=ENTER_SUBBLOCK...): how to read these ID from the file stream ? I mean, I don't know, how many bit length they are. It doesn't exist on the document. - Second, how is the order to read the bytecode ? For

I wrote in a few weeks ago about writing an independent implementation of Bitcode and updating the docs to be more complete. Attached is a patch to docs/BitCodeFormat.html that adds a lot of information that was previously only available by reading the source code. It also corrects some errors. Josh -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, I currently write a tool to parse the LLVM bytecode file (.bc file). So I have some very basic questions: - First, about the Abbreviation ID ( "0"=END_BLOCK, "1"=ENTER_SUBBLOCK...): how to read these ID from the file stream ? I mean, I don't know, how many bit length they are. It doesn't exist on the document. - Second, how is the order to read the bytecode ? For

...ch would accumulate strings > while writing the bitcode module(s) (and symtab in the future). At the end, > the client would call something like BitcodeWriter::writeStrtab() which > would write out the string table. > > >> >> Each STRTAB_BLOCK would apply to all preceding MODULE_BLOCKs. This means >> that bitcode files can continue to be concatenated with "llvm-cat -b". >> (Normally bitcode files would contain a single string table, which in >> multi-module bitcode files would be shared between modules.) >> >> This *almost* allows us to rem...