similar to: [LLVMdev] Bytecode Format Change

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:

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

On Thu, 30 Jun 2005, Tanu Sharma wrote: > I am compiling SPEC 2000 benchmarks with llvm .Got stuck with > calculating "execution time" of all the .bc and native files. > > The log for nightly test itself gives execution times but I am passing > the bytecode files to my pass which gives another bytecode file.I have > to calculate execution time of such bytecode and

Hello All, Thanks for the reply.I can generate the reports by compiling Spec through llvm, but that couldn't resolve my problem. I m trying to determine execution time for the bytecode and native files , which are obtained as a result of running my pass over the original bytecode .I am running these experiments on spec benchmark. In SPEC we have command line tools such as runspec where

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

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

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

On Fri, 2007-03-02 at 17:48 -0600, John Criswell wrote: > Dear All, > > I've just heard that there's been a recent discussion on the IRC channel > about moving the LLVM source repository from CVS to Subversion (SVN) and > that this migration may happen "soon." Yes, its been talked about for ages and its time to do it. We've debated the choice of repositories

Greetings, I am working on a project (unrelated to LLVM) that needed a bytecode-like format. I found Bitcode and it seems to fit the bill really nicely. I am writing an independent implementation of Bitcode in C (I really want to keep my runtime pure C). In the process of doing this, I've discovered a few things I want to ask about. I notice the Bitcode format documentation [0] is

Hi Joshua, On Mon, 2007-09-03 at 21:34 +0000, Joshua Haberman wrote: > Greetings, > > I am working on a project (unrelated to LLVM) that needed a > bytecode-like format. I found Bitcode and it seems to fit the bill > really nicely. > > I am writing an independent implementation of Bitcode in C (I really > want to keep my runtime pure C). In the process of doing this,

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

On Thu, 19 May 2005, Reid Spencer wrote: > I forgot to remove some crud from the configure script and it caused > some of the nightly testers to fail last night. The problem has already > been fixed. Part of the problem was that it took 2 hours to get a commit > through to CVS last night and the nightly tester had already started by > that time. Something needs to be done about the

Hello , I am compiling SPEC 2000 benchmarks with llvm .Got stuck with calculating "execution time" of all the .bc and native files. The log for nightly test itself gives execution times but I am passing the bytecode files to my pass which gives another bytecode file.I have to calculate execution time of such bytecode and native files as well.If i simply do this: time lli

Hi Aaron, On Sun, 2007-02-18 at 20:43 +0000, Aaron Gray wrote: > Hi Reid, > > Cygwin 'sys/resource.h' has get/setrlimit() functions support for > RLIMIT_DATA and RLIMIT_AS but not RLIMIT_RSS. Then, please fix it to not use RLIMIT_RSS in the cygwin case. Perhaps you should just use RLIMIT_AS for cygwin. It will trigger sooner than RLIMIT_RSS but that's probably okay.

On Wed, 30 Aug 2006, Kenneth Hoste wrote: > I've been trying (on and off) to compile the _full_ SPEC CPU2000 benchmark > suite to LLVM bytecode. The biggest problem > I'm facing is the Fortran benchmarks, for which some partial support is > already available it seems (using f2c). ok. > Unfortunately the f2c compiler only allows the translation of Fortran-77 >