similar to: [LLVMdev] The Incredible Shrinking Bytecode File

Displaying 20 results from an estimated 20000 matches similar to: "[LLVMdev] The Incredible Shrinking Bytecode File"

2004 Nov 11
0
[LLVMdev] install-bytecode no longer works
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
2004 Nov 11
0
[LLVMdev] install-bytecode no longer works
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
2004 Nov 11
2
[LLVMdev] install-bytecode no longer works
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
2004 Nov 11
2
[LLVMdev] install-bytecode no longer works
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
2004 Nov 12
2
[LLVMdev] install-bytecode no longer works
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
2004 Nov 12
0
[LLVMdev] install-bytecode no longer works
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
2004 Nov 12
4
[LLVMdev] install-bytecode no longer works
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
2006 Oct 26
0
[LLVMdev] Some basic questions about LLVM version 1.8 bytecode format
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
2006 Oct 25
2
[LLVMdev] Some basic questions about LLVM version 1.8 bytecode format
<!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
2004 Nov 11
2
[LLVMdev] install-bytecode no longer works
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.
2004 Nov 11
0
[LLVMdev] install-bytecode no longer works
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 has hit this snag. The instructions still call > for running "gmake -C runtime install-bytecode", but this target no longer exists. > > _______________________________________________ > LLVM Developers mailing list
2004 Jul 07
0
[LLVMdev] Bytecode Format Documentation For Review
Folks, I have completed a final draft of the bytecode documentation. You can find it in llvm/docs/BytecodeFormat.html in CVS. Or, if you'd prefer to view online, you can find it here: http://llvm.x10sys.com/llvm/docs/BytecodeFormat.html I'm soliciting your feedback on this document. Please let me know if anything is awkward or just plain wrong. Thanks, Reid. -------------- next part
2005 Mar 23
2
[LLVMdev] bytecode -> native code
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': :
2004 Aug 16
2
[LLVMdev] Bytecode file bugs / doc bugs
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
2005 Jan 27
3
the incredible lightness of crossprod
The following is at least as much out of intellectual curiosity as for practical reasons. On reviewing some code written by novices to R, I came across: crossprod(x, y)[1,1] I thought, "That isn't a very S way of saying that, I wonder what the penalty is for using 'crossprod'." To my surprise the penalty was substantially negative. Handily the client had S-PLUS as
2004 Aug 18
0
[LLVMdev] Re: Bytecodes & docs
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
2004 Aug 17
2
[LLVMdev] Re: Bytecodes & docs
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,
2004 Oct 28
1
[LLVMdev] Bytecode Library Names
Some issues about bytecode libraries, their names, and where they get installed need to be discussed. Currently the bytecode libraries are installed to two different places: $(libdir) $(bytecode_libdir) libdir is $(prefix)/lib bytecode_libdir is $(LLVMGCCDIR)/bytecode-libs The things that go into $(libdir) are built from the "runtime" directory but aren't bytecode libraries,
2006 Dec 02
0
[LLVMdev] invalid bytecode signature
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
2006 Dec 02
1
[LLVMdev] invalid bytecode signature
Thank you for the help. There seem to be several things in my makefiles that are messed up as a result of switching from the gcc3.4 front end to the gcc4 frontend. Is there any documentation listing the things that have changed? Thanks, Ryan Ryan M. Lefever [http://www.ews.uiuc.edu/~lefever] On Fri, 1 Dec 2006, Reid Spencer wrote: > Hi Ryan, > > On Fri, 2006-12-01 at 18:06