search for: bitcodewrit

I am currently making some BitcodeWriter changes that involve some refactoring, and am thinking for the Nth time that it would be much nicer to have a class instead of passing around a long list of parameters. I am thinking of biting the bullet and doing that - any objections? I assume the reason why there is no existing class wrapping...

> > I also have a look at the code, looks like it directly parse the bitcode > and build in memory representation in a different LLVM version than the > bitcode. Is this correct? According to your description, I guess the BitCodeWriter should be the one > to do the bitcode version downgrade, right? I think so. I don't know much about it and don't want to give you misleading information; I'm cc-ing Stephen. On 2 August 2016 at 16:53, Hongbin Zheng <etherzhhb at gmail.com> wrote: > Thanks Jakub. Looks...

> On 2016-Apr-21, at 11:41, Mehdi Amini <mehdi.amini at apple.com> wrote: > > >> On Apr 21, 2016, at 11:25 AM, Teresa Johnson <tejohnson at google.com> wrote: >> >> I am currently making some BitcodeWriter changes that involve some refactoring, and am thinking for the Nth time that it would be much nicer to have a class instead of passing around a long list of parameters. I am thinking of biting the bullet and doing that - any objections? > > In general I'm worried about having single g...

.../lib/x86_64-linux-gnu/libc.so.6+0x2e03d) #8 0x00007f04af6bb0f2 (/lib/x86_64-linux-gnu/libc.so.6+0x2e0f2) #9 0x000000000204de7e llvm::ValueEnumerator::getTypeID(llvm::Type*) const /home/pierre/Desktop/llvm/lib/Bitcode/Writer/ValueEnumerator.h:162:0 #10 0x00000000020454cc (anonymous namespace)::ModuleBitcodeWriter::writeInstruction(llvm::Instruction const&, unsigned int, llvm::SmallVectorImpl<unsigned int>&) /home/pierre/Desktop/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp:2509:0 #11 0x00000000020474eb (anonymous namespace)::ModuleBitcodeWriter::writeFunction(llvm::Function const&, llvm::Den...

...lvm at gmail.com> wrote: > >> I also have a look at the code, looks like it directly parse the bitcode >>> and build in memory representation in a different LLVM version than the >>> bitcode. Is this correct? >> >> According to your description, I guess the BitCodeWriter should be the >>> one to do the bitcode version downgrade, right? >> >> I think so. >> >> I don't know much about it and don't want to give you misleading >> information; I'm cc-ing Stephen. >> >> >> On 2 August 2016 at 16:53, H...

...that by proposing a change to the module format so that the block info block is stored at the top level. The next step is to think about what the API would look like for reading and writing multiple modules. Here's what I have in mind. To create a multi-module bitcode file, you would create a BitcodeWriter object and add modules to it: BitcodeWriter W(OS); W.addModule(M1); W.addModule(M2); W.write(); Reading a multi-module bitcode file would be supported with a BitcodeReader class. Each of the functional reader APIs in ReaderWriter.h would have a member function on BitcodeReader. We would also ha...

...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? > 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 ...&g...

Hi all. In the beginning of this method I see the next: for (unsigned i = 0, e = AttrGrps.size(); i != e; ++i) { AttributeSet AS = AttrGrps[i]; for (unsigned i = 0, e = AS.getNumSlots(); i != e; ++i) { AttributeSet A = AS.getSlotAttributes(i); Record.push_back(VE.getAttributeGroupID(A)); Record.push_back(AS.getSlotIndex(i)); for (AttributeSet::iterator I

...r 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? >> > > 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 =...

...roposing a change to the module format so that the block info block is stored at the top level. The next step is to think about what the API would look like for reading and writing multiple modules. > > Here's what I have in mind. To create a multi-module bitcode file, you would create a BitcodeWriter object and add modules to it: > > BitcodeWriter W(OS); > W.addModule(M1); > W.addModule(M2); > W.write(); That requires the two modules to lives longer than the bitcode write, the API could be: BitcodeWriter W(OS); W.writeModule(M1); // delete M1 // ... // create M2 W.writeModul...

...llvm at gmail.com <mailto:kubakuderski+llvm at gmail.com>> wrote: > I also have a look at the code, looks like it directly parse the bitcode and build in memory representation in a different LLVM version than the bitcode. Is this correct? > According to your description, I guess the BitCodeWriter should be the one to do the bitcode version downgrade, right? > I think so. > > I don't know much about it and don't want to give you misleading information; I'm cc-ing Stephen. > > > On 2 August 2016 at 16:53, Hongbin Zheng <etherzhhb at gmail.com <mailt...

...gmail.com <mailto:kubakuderski+llvm at gmail.com>> wrote: >> I also have a look at the code, looks like it directly parse the bitcode and build in memory representation in a different LLVM version than the bitcode. Is this correct? >> According to your description, I guess the BitCodeWriter should be the one to do the bitcode version downgrade, right? >> I think so. >> >> I don't know much about it and don't want to give you misleading information; I'm cc-ing Stephen. >> >> >> On 2 August 2016 at 16:53, Hongbin Zheng <etherzhh...

...nge to the module format so that > the block info block is stored at the top level. The next step is to think > about what the API would look like for reading and writing multiple modules. > > Here's what I have in mind. To create a multi-module bitcode file, you > would create a BitcodeWriter object and add modules to it: > > BitcodeWriter W(OS); > W.addModule(M1); > W.addModule(M2); > W.write(); > > > That requires the two modules to lives longer than the bitcode write, the > API could be: > > BitcodeWriter W(OS); > W.writeModule(M1); > // delet...

...r 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? >> > > 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 =...

...the code, looks like it directly parse the >>>>>>> bitcode and build in memory representation in a different LLVM version than >>>>>>> the bitcode. Is this correct? >>>>>> >>>>>> According to your description, I guess the BitCodeWriter should be >>>>>>> the one to do the bitcode version downgrade, right? >>>>>> >>>>>> I think so. >>>>>> >>>>>> I don't know much about it and don't want to give you misleading >>>>>&...

Hi mailing list, I has been working on a large project that is based on LLVM 3.1. Recently we are thinking to introduce an LLVM bc converter from LLVM 3.9 to LLVM 3.1, such that we can introduce some of the newest LLVM analyses and optimizations to our LLVM 3.1 based project. Have you worked on similar things that converting LLVM bc downward and has anything to share? Thanks Hongbin

...rmat so that the >> block info block is stored at the top level. The next step is to think about >> what the API would look like for reading and writing multiple modules. >> >> Here's what I have in mind. To create a multi-module bitcode file, you >> would create a BitcodeWriter object and add modules to it: >> >> BitcodeWriter W(OS); >> W.addModule(M1); >> W.addModule(M2); >> W.write(); >> >> >> That requires the two modules to lives longer than the bitcode write, the >> API could be: >> >> BitcodeWriter...

...orarily go for the following syntax for BasicBlock metadata (subject to discussion): entry: !property_1 !0, !property_2 !1 %x = fadd float %a, %b It seems that I have to touch lots of files for this: BasicBlock.h/.cpp, Metadata.cpp, LLParser.cpp, AsmParser, AsmWriter, BitcodeReader.cpp, BitcodeWriter.cpp so far. I basically went and duplicated code that handles metadata attached to instructions. Concerning Argument metadata, I am unsure of how to best represent this in LLVM IR. The following seems to be better than putting the metadata somewhere before the first block or anywhere else, bu...

...et the whole program bitcode with debug information in it. I tried to use CFLAGS = "-O4 -g", but it ends with the following error: collect2: ld terminated with signal 6 [Aborted] Unknown constant! UNREACHABLE executed at /local.toadette/aliang/fixing/llvm-2.7/llvm-2.7/lib/Bitcode/Writer/BitcodeWriter.cpp:895! What is the right way to get a whole program bitcode with debug information using gold plugin? Thanks, Guoliang

...ortable way to check if an ostream is the standard output ? Hope this helps, Julien -- Julien Lerouge PGP Key Id: 0xB1964A62 PGP Fingerprint: 392D 4BAD DB8B CE7F 4E5F FA3C 62DB 4AA7 B196 4A62 PGP Public Key from: keyserver.pgp.com -------------- next part -------------- Index: lib/Bitcode/Writer/BitcodeWriter.cpp =================================================================== --- lib/Bitcode/Writer/BitcodeWriter.cpp (revision 51935) +++ lib/Bitcode/Writer/BitcodeWriter.cpp (working copy) @@ -23,6 +23,7 @@ #include "llvm/TypeSymbolTable.h" #include "llvm/ValueSymbolTable.h" #...