search for: module_block

...their first operand would specify their names > with a byte offset into the string table. (To allow for backwards > compatibility, I would increment the bitcode version.) > > > I assume you mean the EPOCH? > > Here is what it would look like as bcanalyzer output: > > <MODULE_BLOCK> > <VERSION op0=2> > <COMDAT op0=0 ...> ; name = foo > <FUNCTION op0=0 ...> ; name = foo > <GLOBALVAR op0=4 ...> ; name = bar > <ALIAS op0=8 ...> ; name = baz > ; function bodies, etc. > </MODULE_BLOCK> > <STRTAB_BLOCK>...

...CODE_{FUNCTION,GLOBALVAR,ALIAS,IFUNC,COMDAT} records would change so that their first operand would specify their names with a byte offset into the string table. (To allow for backwards compatibility, I would increment the bitcode version.) Here is what it would look like as bcanalyzer output: <MODULE_BLOCK> <VERSION op0=2> <COMDAT op0=0 ...> ; name = foo <FUNCTION op0=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\0...

...he ThinLTO information, and vice versa. Bitcode ThinLTO Support This section describes the representation of ThinLTO for bitcode-only intermediate files. ThinLTO Bitcode Blocks There will be three ThinLTO bitcode blocks nested within an outer THINLTO_BLOCK, which itself is nested within the outer MODULE_BLOCK: <MODULE_BLOCK> ... <THINLTO_BLOCK BlockID=19 ...> <THINLTO_SYMTAB_BLOCK BlockID=20 ...> </THINLTO_SYMTAB_BLOCK> <THINLTO_MODULE_STRTAB_BLOCK BlockID=21 ...> </THINLTO_MODULE_STRTAB_BLOCK> <THINLTO_FUNCTION_SUMMARY_BLOCK BlockID=22 ......

...uld increment the bitcode version.) > > > I assume you mean the EPOCH? > No, the MODULE_CODE_VERSION. http://llvm-cs.pcc.me.uk/lib/Bitcode/Writer/BitcodeWriter.cpp#3822 It isn't clear to me why we have both. > Here is what it would look like as bcanalyzer output: > > <MODULE_BLOCK> > <VERSION op0=2> > <COMDAT op0=0 ...> ; name = foo > <FUNCTION op0=0 ...> ; name = foo > <GLOBALVAR op0=4 ...> ; name = bar > <ALIAS op0=8 ...> ; name = baz > ; function bodies, etc. > </MODULE_BLOCK> > <STRTAB_BLOCK>...

...gt;> I assume you mean the EPOCH? >> > > No, the MODULE_CODE_VERSION. > http://llvm-cs.pcc.me.uk/lib/Bitcode/Writer/BitcodeWriter.cpp#3822 > It isn't clear to me why we have both. > > >> Here is what it would look like as bcanalyzer output: >> >> <MODULE_BLOCK> >> <VERSION op0=2> >> <COMDAT op0=0 ...> ; name = foo >> <FUNCTION op0=0 ...> ; name = foo >> <GLOBALVAR op0=4 ...> ; name = bar >> <ALIAS op0=8 ...> ; name = baz >> ; function bodies, etc. >> </MODULE_BLOCK&g...

.... > Bitcode ThinLTO Support > > This section describes the representation of ThinLTO for bitcode-only > intermediate files. > ThinLTO Bitcode Blocks > > There will be three ThinLTO bitcode blocks nested within an outer > THINLTO_BLOCK, which itself is nested within the outer MODULE_BLOCK: > > <MODULE_BLOCK> > > ... > > <THINLTO_BLOCK BlockID=19 ...> > > <THINLTO_SYMTAB_BLOCK BlockID=20 ...> > > </THINLTO_SYMTAB_BLOCK> > > <THINLTO_MODULE_STRTAB_BLOCK BlockID=21 ...> > > </THINLTO_MODULE_STRTAB_...

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

...t;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 example 4 bytes after the LLVM IR magic nr.: 21 0C 00 00 It describes the MODULE_BLOCK with its parameters, actually. But I don't know how to extract them from those bytes. I hope that somebody can help me answer these questions. Thanks and Regards, Quang

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:

...t;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 example 4 bytes after the LLVM IR magic nr.: 21 0C 00 00 It describes the MODULE_BLOCK with its parameters, actually. But I don't know how to extract them from those bytes. I hope that somebody can help me answer these questions. Thanks and Regards, Quang

...gt;> I assume you mean the EPOCH? >> > > No, the MODULE_CODE_VERSION. > http://llvm-cs.pcc.me.uk/lib/Bitcode/Writer/BitcodeWriter.cpp#3822 > It isn't clear to me why we have both. > > >> Here is what it would look like as bcanalyzer output: >> >> <MODULE_BLOCK> >> <VERSION op0=2> >> <COMDAT op0=0 ...> ; name = foo >> <FUNCTION op0=0 ...> ; name = foo >> <GLOBALVAR op0=4 ...> ; name = bar >> <ALIAS op0=8 ...> ; name = baz >> ; function bodies, etc. >> </MODULE_BLOCK&g...