similar to: [LLVMdev] goodbye bytecode, hello bitcode

> Please let me know if you run into any problems. Documentation of the > file format is in the works. The bytecode support code is still in the > tree, but isn't being built. Assuming no major problems, I will remove > the old code tomorrow. I am getting a missing 'lib/Archive' directory when making from an updated CVS. Aaron

On Mon, 2007-05-07 at 21:12 +0100, Aaron Gray wrote: > > Please let me know if you run into any problems. Documentation of the > > file format is in the works. The bytecode support code is still in the > > tree, but isn't being built. Assuming no major problems, I will remove > > the old code tomorrow. > > I am getting a missing 'lib/Archive' directory

Anyone, can you say what was the reason to rename bytecode? I am still interesting in 2010/9/29 Duncan Sands <baldrick at free.fr> Hi Ariel, > As long as I know English the word "bit" is a "small pice", . Why in set of > documentation ir is "bytecode", in other set or llvm source is "bitecode"? > What is the right? Different people call the

I did this short experiment: ggreif at my [!297] cd /home/ggreif/llvm ggreif at my [!298] find . -name "*.cpp" | xargs grep bytecode | wc -l 143 I guess these are a quick prey for perl's in-place replace. But wait! There are more: ggreif at my [!299] find . -name "*.cpp" | xargs grep -i bytecode | wc -l 291 probably all of the rest is "Bytecode"

Hi list, As long as I know English the word "bit" is a "small pice", . Why in set of documentation ir is "bytecode", in other set or llvm source is "bitecode"? What is the right? Different people call the same thing such differently. -- best regards Ariel -------------- next part -------------- An HTML attachment was scrubbed... URL:

Chris rewrote the original LLVM bytecode into it's present bitcode form. The newer code is much smaller than the previous form. That would be my guess for why he chose to call it bitcode. Of course, he can say for himself. :-) -bw On Sep 29, 2010, at 5:15 AM, Ariel Feinerman wrote: > Anyone, > > can you say what was the reason to rename bytecode? I am still interesting in >

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

I am getting an "--emit-llvm is not supported in this configuration" error on a release build on Cygwin, the debug build is fine. make[3]: Entering directory `/usr/build/llvm/runtime/GCCLibraries/libc' llvm[3]: Compiling atox.c for Release build (bytecode) llvm-gcc: --emit-llvm is not supported in this configuration. make[3]: ***

Sorry if I'm repeating something that was already said. I was just thinking "why the heck do I seem headed for JVM generation if what I want to use is LLVM", and this is the result: I'm coming from a Java background. I'm using Eclipse, I'm used to the syntax highlighting, cross referencing and refactoring support that Eclipse offers. I know I will want to have the

> Ok, less talk and more action. I just implemented proper Microsoft > ML/MASM support. It probably has a few rough edges, so if anyone wants to > try it out please do and let me know if you encounter any problems. > > Note that you cannot take a bytecode file created by llvm-gcc on Unix, > move it to Windows, translate it to Intel syntax assembler, assemble it > with ML

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

Kenneth Hoste wrote: > John Criswell wrote: >> Okay. As Rob has already said, it sounds like you want to write an >> LLVM pass that adds global variables and instructions to a program. >> So, to state it explicitly, you want to: >> >> 1) Compile the program that you want to instrument to LLVM bytecode >> using llvm-gcc. >> 2) Use an LLVM pass that

Some wheird problem, Target/X86 builds okay now. But there seems to be another problem with the Cygwin build :- make[4]: Entering directory `/usr/build/llvm/lib/Target/SparcV9/ModuloScheduling' llvm[4]: Compiling ModuloSchedulingSuperBlock.cpp for Debug build /usr/src/llvm/lib/Target/SparcV9/ModuloScheduling/ModuloSchedulingSuperBlock.cpp : In member function `virtual bool

John Criswell wrote: > You can compile library code into LLVM bytecode libraries and link them > with gccld. In general, LLVM provides tools equivalent to most of your > compiler tool chain (gccas, gccld, llvm-ar, llvm-nm, etc). You can, for > example, make an archive of LLVM bytecode files. > > The problem, in your case, is that no one has successfully compiled all >

Hi Ariel, > can you say what was the reason to rename bytecode? I am still interesting in you forgot to send this to the mailing list, so I have (probably someone there knows better than I). I think the reason is that bitcode is bit-packed, i.e. you can have multiple pieces of information stored in one byte, so byte code was a misnomer. Ciao, Duncan. > > 2010/9/29 Duncan Sands

John Criswell wrote: > Okay. As Rob has already said, it sounds like you want to write an LLVM > pass that adds global variables and instructions to a program. So, to > state it explicitly, you want to: > > 1) Compile the program that you want to instrument to LLVM bytecode > using llvm-gcc. > 2) Use an LLVM pass that you write to instrument the program. > 3) Use

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

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.

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached

Le Sat, May 12, 2007 at 04:42:49PM -0700, Chris Lattner écrivait/wrote: > On Sat, 12 May 2007, Basile STARYNKEVITCH wrote: > > with the latest LLVM (almost 2.0 CVS) what is the right way to read a module > > from a byte array fetched from a database? > > The bitcode reader will read from any MemoryBuffer object. There are a > variety of static methods on MemoryBuffer to