similar to: [LLVMdev] Bytecode Change

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, 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 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:

On Wed, Jan 21, 2004 at 08:25:23AM -0800, Robert Mykland wrote: > I'm the guy who is working on the LLVM bytecode documentation. The > document I have at present just supports the bytecodes my code > generator processes, though, which is far from all of them. As I get > farther along with my code generator I expect I'll get to the point > where everything kind of fits

Reid, Thanks for the detailed feedback. A value of zero now means zero literal for everything except labels, right? There is kind of a vague reference to this in the 1.0 -> 1.1 section I believe. You might want to make this clearer when talking about values in the body of the document. --> A comment on this: if a value of zero were never used for labels, that would make me happy,

I'm the guy who is working on the LLVM bytecode documentation. The document I have at present just supports the bytecodes my code generator processes, though, which is far from all of them. As I get farther along with my code generator I expect I'll get to the point where everything kind of fits together for me and I can finish it up. In the meantime, people are welcome to what I have

But there already was an "install", and it did far more than install the bytecode files. That changed too? On Wed, 10 Nov 2004 23:28:27 -0800 Reid Spencer <reid at x10sys.com> wrote: > Yeah, its just "install" now. > > I'll fix the documentation. > > Reid. > > On Wed, 2004-11-10 at 23:19, Jeff Cohen wrote: > > My rebuild from scratch

Wow... it is nearly twice as fast. But it tried to install stuff in /usr/local (and as I wasn't root...) and it didn't do that before. As I don't care about profiling or tracing, I didn't bother to su and do it again. On Wed, 10 Nov 2004 23:45:35 -0800 Reid Spencer <reid at x10sys.com> wrote: > The entire makefile system was rewritten a couple of weeks ago. This is

Hi Ryan, On Fri, 2006-12-01 at 18:06 -0600, Ryan M. Lefever wrote: > I am trying to disassemble some bytecode using llvm-dis: > llvm-dis -f -o llvmtest/sliceme2.cbc.ll llvmtest/sliceme2.cbc > > However, I am getting the following error. > > llvm-dis: Invalid bytecode signature: 464C457F (Vers=0, Pos=4) The problem is most likely that sliceme2.cbc is *not* bytecode. Open the

The default prefix is /usr/local but I would recommend that when you configure LLVm you do so with: configure --prefix=/me/llvm/install/dir ... so that installation occurs in a place you have write access. If you feel strongly about restoring the install-bytecode target, feel free to file a bug. Reid. On Thu, 2004-11-11 at 09:12, Jeff Cohen wrote: > Wow... it is nearly twice as fast. But

I am trying to obtain native code from the bytecode by using commands: % llc hello.bc -o hello.s % gcc hello.s -o hello.native This is working for a simple program( a single source file) but when I try to run it on grep utility (grep.bc) , it gives me the following error: $ llc grep.bc -o grep.s $ gcc grep.s -o grep.native /tmp/ccY3oNAA.o(.text+0x2f2f): In function `main': :

The entire makefile system was rewritten a couple of weeks ago. This is a good thing, your compiles now go twice as fast. Resistance is futile, just adapt :) The install target installed the bytecode libs into CFEINSTALL as before and also installs the native libraries to your prefix/lib directory. This is intentional. Reid On Wed, 2004-11-10 at 23:32, Jeff Cohen wrote: > But there already

I am trying to disassemble some bytecode using llvm-dis: llvm-dis -f -o llvmtest/sliceme2.cbc.ll llvmtest/sliceme2.cbc However, I am getting the following error. llvm-dis: Invalid bytecode signature: 464C457F (Vers=0, Pos=4) How do I go about figuring out what the problem is? llvmtest/sliceme2.cbc is newly compiled using the same version of llvm-gcc as llvm-dis. -- Ryan M. Lefever

This kind of thing is one of the many reasons we broke llvm-test out to a separate project. It has multiple purposes. Its a correctness test on LLVM, its what we base our compiler benchmarks on, and its also where a lot of the research gets done. You've been bitten by the latt(n)er. :) At some point I'd like to see us make some distinctions so that there is a correctness test suite whose

No, I don't feel strongly about it... it's just annoying to have things change on me that break habits :) On the other hand, I do feel strongly about the tests in llvm-test that are now failing on me because they explicitly include alloca.h, a file that does not exist on FreeBSD. I can supply a patch to take out the include, of course, but the problem then becomes that the tests will

All, Last night I removed compaction tables from the bytecode format (documentation change forthcoming). This was done for a few reasons. First, its very expensive in CPU time to process compaction tables for both reading and writing. Second, the maximum benefit we gained was about 7% (600K a 9Mb bytecode). In most cases its in the 1% range or actually makes the bytecode larger. Finally, as we

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

Okay I have put a #ifdef HAVE_RLIMIT_RSS round the RSS code. There needs to be logic added to config system to complement this. Or shall I just use an #ifdef _CYGWIN_ ? Regarding the Bytecode writer stuff. I will try adding some inline dis-ambiguator functions. Aaron ----- Original Message ----- From: "Reid Spencer" <rspencer at reidspencer.com> To: "LLVM Developers

Dear Reid and Chris, I thought I should send this to the list in case anyone else is struggling to interpret bytecode files with the new docs. (1) First a bug I already mentioned to Reid. Unlike the other new module headers module 0x01 still uses the old 32-bit and 32-bit format instead of the new 5-bit and 27-bit format. Thus the first module in the file will be 0x00000001 followed by

My rebuild from scratch has hit this snag. The instructions still call for running "gmake -C runtime install-bytecode", but this target no longer exists.