similar to: [LLVMdev] Bytecode Format Documentation For Review

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,

MOre feedback inline ... Robert Mykland wrote: > Reid, > > Thanks for the detailed feedback. Sure .. devil's in the details :) > A value of zero now means zero literal for everything except labels, > right? Hmm. Not quite sure what you mean here. Zero values are used in quite a few places for various purposes. For example, the zlist will write a zero byte to terminate

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

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

On Thu, 11 Nov 2004, Reid Spencer wrote: > 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

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

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

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

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

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

Hi Robert, On Wed, 2006-10-25 at 16:00 -0600, Robert Mykland wrote: > I generated LLVM bytecode for a "hello world!" program just to get the > basic bytecode structure. I have a few questions about the global > info module and the global constants module where there have > apparently been changes since 1.4. Okay. > I would be happy to collect these differences and do

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> I generated LLVM bytecode for a "hello world!" program just to get the basic bytecode structure. I have

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? Thanks a bunch. --Grant

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

Yet Another Byte Code Format Change: Yup, just when you got over the last bytecode change, its changed again. In order to support shifts of more than 255 bits for large integer types, it was necessary to make the ShiftInst become a BinaryOperator. This means the three shift instruction's opcodes had to be moved into the BinaryOps range and consequently all the opcodes after that got bumped

Dear All, Would somebody be able to update the Bytecode Format Manual with the 28 bit bytecode version numbers for LLVM 1.4, 1.5, and 1.6 (or point me to the file which defines it so I can look it up)? Thanks. -- John T. -- John T. Criswell Research Programmer University of Illinois at Urbana-Champaign "It's today!" said Piglet. "My favorite day," said Pooh.

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

Hello Everyone. I'm going to break bytecode format a little bit. This is need to support function aliases. The corresponding patch was sent to llvm-commits for review (http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070416/047998.html). However, I tried to make things as much backward-compatible, as I can. Your bytecodes will be broken only if you're using module-wide

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

Domagoj, > Is that change absolutely necessary? Unfortunately, yes. We're having at least two PRs opened for aliases including libstdc++ compilation in shared mode for x86/linux. > I've just spent 2 days compiling benchmarks. So, now I'd need to > ditch all that and start from scratch... No. Bytecode will be breaking only if it have module-wide assembler. I don't think