similar to: [LLVMdev] Bytecode Reader (CVS Head)

Hi Roman, On Tue, 2006-12-19 at 17:32 -0800, Roman Levenstein wrote: > Hi, > > I just updated my LLVM sources from CVS/HEAD and rebuilt them. And I > downloaded the GCC4 frontend from the 1.9 release. > > Now I cannot compile anything, since GCC frontend seems to produce BC > files that cannot be read by llvm-dis, llc and other utils. > > llvm-dis shows a following

Hi Reid, --- Reid Spencer <rspencer at reidspencer.com> wrote: > On Tue, 2006-12-19 at 17:32 -0800, Roman Levenstein wrote: > > But since the new llvm-dis cannot disassemble, I cannot use > > llvm-upgrade, since I need a way to produce an *.ll file. > > If you can't do as Bill suggested (get the latest llvm-gcc and > compile > it), you can use this approach:

Ryan, This looks like a bug. Could you file it, please? Reid. On Thu, 2007-02-22 at 19:47 -0600, Ryan M. Lefever wrote: > I have a compiler transform that I have been working on that produces > bytecode that passes the verifier. However, when I try to read that > bytecode back in, I get the assertion failure below. > > llvm::BytecodeReader::ParseConstantPoolValue(unsigned

I am still diagnosing the cause of the assertion failure and will submit a bug when I better understand the problem. Reid Spencer wrote: > Ryan, > > This looks like a bug. Could you file it, please? > > Reid. > > On Thu, 2007-02-22 at 19:47 -0600, Ryan M. Lefever wrote: > >>I have a compiler transform that I have been working on that produces >>bytecode

I have a compiler transform that I have been working on that produces bytecode that passes the verifier. However, when I try to read that bytecode back in, I get the assertion failure below. llvm::BytecodeReader::ParseConstantPoolValue(unsigned int): Assertion `(!isa<Constant>(Result) || !cast<Constant>(Result)->isNullValue()) || !hasImplicitNull(TypeID) &&

Hi, I just updated my LLVM sources from CVS/HEAD and rebuilt them. And I downloaded the GCC4 frontend from the 1.9 release. Now I cannot compile anything, since GCC frontend seems to produce BC files that cannot be read by llvm-dis, llc and other utils. llvm-dis shows a following message: Bytecode formats < 7 are not longer supported. Use llvm-upgrade. (Vers=6, Pos=9) But since the new

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

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

All, Our plan in 2.0 for backwards compatibility with llvm-1.9 is to provide a translator for upgrading from 1.9 to 2.0 llvm assembly. The tool will be named llvm-upgrade and used something like this: llvm-1.9/bin/llvm-dis < 1.9.bc | llvm-2.0/bin/llvm-upgrade | llvm-2.0/bin/llvm-as -o 2.0.bc The 2.0 assembly and bytecode are going to be significantly different and this approach offers us a

All, As you may know, I'm working on making several instructions have signed and/or floating point variants. For example, yesterday I committed changes to replace the DIV instruction with SDIV, UDIV, and FDIV. These instruction changes are increments towards getting rid of signed types completely in LLVM. To reduce confusion, here's some things you need to know if you're planning to

Which bytecode files? Perhaps the ones in the runtime library? If these were built with Bytecode V6, then the reader (V5) will not read them. Chris Lattner wrote: > On Wed, 12 Oct 2005 shding at mtu.edu wrote: > >> For some reason, I changed the files /ByteCode/Writer/Writer.cpp and >> /ByteCode/Reader/Reader.cpp and I introduced an new version number 6. >> Now I

Hi: For some reason, I changed the files /ByteCode/Writer/Writer.cpp and /ByteCode/Reader/Reader.cpp and I introduced an new version number 6. Now I replaced these two changed files with the original ones that are version 5. And I rebuild the llvm compiler. What make me mad is that the bytecode produced now is still version 6! Of course the reader cannot recognize it because the current reader

On Wed, 12 Oct 2005 shding at mtu.edu wrote: > For some reason, I changed the files /ByteCode/Writer/Writer.cpp and > /ByteCode/Reader/Reader.cpp and I introduced an new version number 6. > Now I replaced these two changed files with the original ones that are > version 5. And I rebuild the llvm compiler. What make me mad is that > the bytecode produced now is still version 6! Of

All, Post 1.9 we will start using bytecode version 7. Version 6 corresponds to release 1.9. There is some work that needs to be done to make this happen but I'm too tired to think through it right now. I will address this first thing in the morning. In the meantime, the CVS head version of LLVM just changed what version 6 bytecodes means. That means your old version 6 bytecode (before the

On Thu, 8 Jan 2004, Grant Gould wrote: Dear Mr. Gould, > Is there any documentation of the llvm bytecode format? I looked > around the website but didn't see any; did I miss some obvious > document? At this time, we do not have any documentation on the bytcode format. I believe one LLVM user was working on such a document at one time, but if so, it is not complete. One option

I just checked in the final bits to switch us over from bytecode to bitcode. Old bytecode files will not work, but I expect this format to be stable going forward with the 2.x series of releases. This new format has a number of advantages. In particular: 1. The files are smaller. 2. The reader takes about 2/3 the memory it did before. 3. The reader is about 1/2 the code size of the old

Hi, I'm changing bytecode format a little bit, i.e. for 2 operands Instructions, the original is like this: 01-00:Opcode type 07-02:Opcode 15-08: Instruction type 23-16: Operand#1 31-24: Operand#2 My change is like this: 01-00:Opcode type 07-02:Opcode 15-08: Instruction type 16: myflag1 17: myflag2 24-18: Operand#1 31-25: Operand#2 I do

Hi, I am back into working on LLVM now and am having problems with Cygwin builds. Problems with both the 1.9 Release and the CVS on Cygwin... LLVM CVS Release build :- /usr/src/llvm/configure --prefix=/usr/llvm make tools-only ENABLE_OPTIMIZED=1 make[3]: Entering directory `/usr/src/lib/Bytecode/Writer' llvm[3]: Compiling SlotCalculator.cpp for Release build llvm[3]: Compiling

-----Original Message----- From: Vikram S. Adve [mailto:vadve at cs.uiuc.edu] Sent: Sunday, January 25, 2004 7:16 AM To: Joseph E. Grzywacz Subject: RE: [LLVMdev] Basic Blocks: Bytecode -> Native Code [Joseph, I'm sending this again because I didn't copy the list the first time.] Yes, this is true for the Sparc back-end. In fact, it is a fundamental assumption that is relied on by

On Tue, Nov 21, 2006 at 05:33:32PM +0800, Mohd-Hanafiah Abdullah wrote: > Emil: > > I'm using LLVM 1.9 now. When I tried to do what you did I got the > following though: > > $ llvm-g++ -emit-llvm -c x.cpp > $ llvm-link -o=linked.o x.o std/*.o sup/*.o > WARNING: Linking two modules of different target triples! > WARNING: Linking two modules of different target