search for: abbrevid

...> behavior: > > (snip) I've ran the good and bad bitcode files for a more compact example (attached) through llvm-bcanalyzer and diff: --- bad.xml 2013-01-09 22:57:58.691131492 +0400 +++ good.xml 2013-01-09 22:58:04.153133734 +0400 ... irrelevant ... <STRUCT_NAME abbrevid=7 op0=105 op1=46 op2=78 op3=105 op4=108 op5=67 op6=108 op7=97 op8=115 op9=115/> <STRUCT_NAMED abbrevid=8 op0=0 op1=0 op2=6/> <POINTER abbrevid=4 op0=7 op1=0/> - <STRUCT_ANON abbrevid=6 op0=0 op1=0 op2=6/> </TYPE_BLOCK_ID> <GLOBALVAR abbrevid=4 o...

Hello. I've managed to create a bitcode file (attached; also available at [1]) which produces a series of identical errors when verified: | Global variable initializer type does not match global variable type! | %i.NilClass* @nil When ran through llvm-dis and recompiled, through, it verifies successfully. If I disassemble it one more time, the result is identical to the first

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:

...itstreamReader.h b/include/llvm/Bitcode/BitstreamReader.h > index 3daef78..840f57e 100644 > --- a/include/llvm/Bitcode/BitstreamReader.h > +++ b/include/llvm/Bitcode/BitstreamReader.h > @@ -409,7 +409,7 @@ public: > } > > /// EnterSubBlock - Having read the ENTER_SUBBLOCK abbrevid, enter > - /// the block, and return true if the block is valid. > + /// the block, and return true if the block has an error. > bool EnterSubBlock(unsigned BlockID, unsigned *NumWordsP = 0) { > // Save the current block's state on BlockScope. > BlockScope.push_bac...

...mbined > summary, and by creating > Assuming I understand this correctly, that means that there would be some kind of type table section in the combined summary index bitcode file, that would look something like the following for the above case: <TYPEID_SUMMARY_BLOCK ...> <TYPE abbrevid=... resolutionid, "typeid3"> </TYPEID_SUMMARY_BLOCK> and included in the on-disk summary as a StringMap, right? > definitions of each of the symbols that shall be required to satisfy the > link time dependencies in the individual ThinLTO modules. Here is an > example...

Hi all, As promised, here is a brain dump on how I see CFI for vcalls working under ThinLTO. Most of this has been prototyped, so the design does appear to be sound. For context on how CFI currently works under regular LTO, please read: http://llvm.org/docs/TypeMetadata.html http://clang.llvm.org/docs/ControlFlowIntegrityDesign.html http://clang.llvm.org/docs/LTOVisibility.html ==== Summary

Hi all, I've been looking into how to make llvm bitcode files smaller. There is one simple change that appears to shrink linked bitcode files by about 15%. See this spreadsheet for some rough data: https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E The change is in how operand ids are encoded in bitcode files. Rather than use an "absolute