search for: llvmbitcod

Hello; I wanted to insert two new terminator instructions in LLVM IR. I modified the necessary files (as mentioned in the tutorial in LLVM site and some more to meet the new structure of LLVM, (e.g no Lexer.l now, we have LLLexer.cpp. Again in the tutorial, files like LLVMBitCodes.h, include/llvm-c/core.h that need to be modified are not mentioned) But I am getting the error while building LLVM. The SelectionDagBuilder.cpp file is giving the error. *In file included from /home/arnie/llvm-svn/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:946:0: * */home/arnie/llvm...

...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_back(Block(CurCodeSize)); > diff --git a/include/llvm/Bitcode/LLVMBitCodes.h b/include/llvm/Bitcode/LLVMBitCodes.h > index c1dc190..6c81739 100644 > --- a/include/llvm/Bitcode/LLVMBitCodes.h > +++ b/include/llvm/Bitcode/LLVMBitCodes.h > @@ -33,9 +33,9 @@ namespace bitc { > UNUSED_ID1, > > CONSTANTS_BLOCK_ID, > - FUNCTION_BLOCK_ID, &g...

...FUNC_CODE_INST_STORE (which can't involved > addr spaces) and FUNC_CODE_INST_STORE2 (which can). The .bc writer > can > switch to unconditionally writing out stores in FUNC_CODE_INST_STORE2 > format. > > Please add a generous block comment to > llvm/include/llvm/Bitcode/LLVMBitCodes.h above the new enum explaining > what the difference is though. :) Should I take the same approach to the encoding of pointer types in the pointer table? -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/piperm...

...> Nitpick: 80-cols in BitcodeReader.cpp > > Since Instruction::FastMathFlags is a class, seems like the constructor could take in Record[OpNum] , and assign the flags. > I like the intent, but unfortunately Record[OpNum] is just a uint64_t. The agreement of which bit means what is in LLVMBitCodes.h, and I'd prefer not having an implicit handshake between the bitcode and the rest of LLVM. However, I'll try to find ways to factor more convenience into shared code. > Looking forward to the full patch. > > Joe Thanks for the feedback!

On Nov 14, 2012, at 5:13 PM, Michael Ilseman <milseman at apple.com> wrote: > I attached a working patch of changes to the bitcode reader and writer. This patch references other local changes I have to other parts of the code (e.g. "FastMathFlags"), but shows the general idea I'm going for. When I've ironed out all the bugs, I'll attach a series of patches for all

...>> involved >> addr spaces) and FUNC_CODE_INST_STORE2 (which can). The .bc >> writer can >> switch to unconditionally writing out stores in FUNC_CODE_INST_STORE2 >> format. >> >> Please add a generous block comment to >> llvm/include/llvm/Bitcode/LLVMBitCodes.h above the new enum >> explaining >> what the difference is though. :) > Should have said: > Should I take the same approach to the encoding of pointer types in > the types table? -- Christopher Lamb -------------- next part -------------- An HTML attachment was sc...

...#). The reader should read both FUNC_CODE_INST_STORE (which can't involved addr spaces) and FUNC_CODE_INST_STORE2 (which can). The .bc writer can switch to unconditionally writing out stores in FUNC_CODE_INST_STORE2 format. Please add a generous block comment to llvm/include/llvm/Bitcode/LLVMBitCodes.h above the new enum explaining what the difference is though. :) Thanks Christopher, -Chris -- http://nondot.org/sabre/ http://llvm.org/

...> >> I think I missed what problem we're trying to solve here. >> >> I'm looking at implementing the bitcode now. I have code to successfully read and write out the LLVM IR textual formal (LLParser, etc) and set the corresponding SubclassOptionalData bits. Looking at LLVMBitCodes.h, I'm seeing where these bits reside in the bitcode, so I believe that things should be pretty straight-forward from here. >> >> Joe, what are the reasons for me to increment the IR version number? My understanding is that I'll just be using existing bits that were previousl...

...le.com> wrote: > I think I missed what problem we're trying to solve here. > > I'm looking at implementing the bitcode now. I have code to successfully read and write out the LLVM IR textual formal (LLParser, etc) and set the corresponding SubclassOptionalData bits. Looking at LLVMBitCodes.h, I'm seeing where these bits reside in the bitcode, so I believe that things should be pretty straight-forward from here. > > Joe, what are the reasons for me to increment the IR version number? My understanding is that I'll just be using existing bits that were previously ignore...

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

>>> Please add a generous block comment to >>> llvm/include/llvm/Bitcode/LLVMBitCodes.h above the new enum >>> explaining >>> what the difference is though. :) >> > > Should have said: > >> Should I take the same approach to the encoding of pointer types in >> the types table? PointerTypes are a bit easier. The code to write them...

...zations on all call sites within the marked function. > > The patch to add support for the corresponding source-level function attribute is here: > http://reviews.llvm.org/D12922 > > http://reviews.llvm.org/D12923 > > Files: > docs/LangRef.rst > include/llvm/Bitcode/LLVMBitCodes.h > include/llvm/IR/Attributes.h > include/llvm/IR/Instructions.h > lib/AsmParser/LLLexer.cpp > lib/AsmParser/LLParser.cpp > lib/AsmParser/LLToken.h > lib/Bitcode/Reader/BitcodeReader.cpp > lib/Bitcode/Writer/BitcodeWriter.cpp > lib/CodeGen/Selectio...

On Nov 11, 2007, at 9:52 AM, Chris Lattner wrote: > > On Nov 10, 2007, at 11:07 PM, Christopher Lamb wrote: > >> I've been playing around with clang/LLVM looking at adding partial >> support for the draft technical report for embedded C extensions >> (TR18037, http://www.open-std.org/jtc1/sc22/wg14/www/docs/ >> n1169.pdf), specifically named address

...bles to locals. > > The norecurse attribute indicates that the function does not call itself either directly or indirectly down any possible call path. > > Repository: > rL LLVM > http://reviews.llvm.org/D14227 > > Files: > docs/LangRef.rst > include/llvm/Bitcode/LLVMBitCodes.h > include/llvm/IR/Attributes.h > include/llvm/IR/Function.h > lib/AsmParser/LLLexer.cpp > lib/AsmParser/LLParser.cpp > lib/AsmParser/LLToken.h > lib/Bitcode/Reader/BitcodeReader.cpp > lib/Bitcode/Writer/BitcodeWriter.cpp > lib/IR/Attributes.cpp > lib...

...right starting point be to simply add an MDNode pointer to the Type class? That should be then convertible to a DIType? The next step apparently would be to support to LLParser to read in such associations, and to AsmPrinter to print it out. But how about the bitcode? Would this require a new LLVMBitCode? With that, would LLVM be able to deal with the type-associated metadata, or is there something in the LLVM side that I'm missing? Once that works, I guess I need to ask how to extend clang to emit the information, but the right place for that would be cfe-dev, wouldn't it? --Pekka Ni...

...gt; >> either directly or indirectly down any possible call path. > >> > >> Repository: > >> rL LLVM > >> > >> http://reviews.llvm.org/D14227 > >> > >> Files: > >> docs/LangRef.rst > >> include/llvm/Bitcode/LLVMBitCodes.h > >> include/llvm/IR/Attributes.h > >> include/llvm/IR/Function.h > >> lib/AsmParser/LLLexer.cpp > >> lib/AsmParser/LLParser.cpp > >> lib/AsmParser/LLToken.h > >> lib/Bitcode/Reader/BitcodeReader.cpp > >> lib/Bitcode/W...

...t; >> The patch to add support for the corresponding source-level function attribute is here: >> http://reviews.llvm.org/D12922 >> >> http://reviews.llvm.org/D12923 >> >> Files: >> docs/LangRef.rst >> include/llvm/Bitcode/LLVMBitCodes.h >> include/llvm/IR/Attributes.h >> include/llvm/IR/Instructions.h >> lib/AsmParser/LLLexer.cpp >> lib/AsmParser/LLParser.cpp >> lib/AsmParser/LLToken.h >> lib/Bitcode/Reader/BitcodeReader.cpp >> lib/Bitco...

On Jul 13, 2011, at 4:26 AM, Anton Lokhmotov wrote: > Hi Chris, > > We have updated the half patch for TOT. Could you review please? Sorry for the delay, some thoughts: +++ b/include/llvm/Bitcode/LLVMBitCodes.h @@ -110,10 +110,12 @@ namespace bitc { TYPE_CODE_METADATA = 16, // METADATA TYPE_CODE_X86_MMX = 17, // X86 MMX + + TYPE_CODE_HALF = 18, // IEEE HALF (16-bit fp) - TYPE_CODE_STRUCT_ANON = 18, // STRUCT_ANON: [ispacked, eltty x N] - TYPE_CODE_STRUCT_NAME...

...in BitcodeReader.cpp >> >> Since Instruction::FastMathFlags is a class, seems like the constructor could take in Record[OpNum] , and assign the flags. >> > > I like the intent, but unfortunately Record[OpNum] is just a uint64_t. The agreement of which bit means what is in LLVMBitCodes.h, and I'd prefer not having an implicit handshake between the bitcode and the rest of LLVM. However, I'll try to find ways to factor more convenience into shared code. It's also a current design policy to explicitly enumerate the bitcode code separately from internal codes. This is...

...able to give me some more insight on what I'm planning to do. :) I would like to store some llvm ir to a custom bitcode format. (Let's say I have 5 different versions of very similar looking bitcode, where the only difference are the enum numbers of each bitcode (see /include/llvm/Bitcode/LLVMBitCodes.h)) The bitcode format will depend on the instructions in the ir. For example when coming across an "add" instruction when converting to bitcode I want to use another bitcode representation then the one the previous instruction used. Could I perhaps do this by adjusting the function Wr...