search for: bytcod

.../llvm-dev/N3r_a1Vbrog/discussion> . * But since llvm3 and type system rewrite, is it a good idea to rethink about a VM wich could run the IR bytecode directly? llvm has differents bytecode from low level, to more hight level... So do you see some interest to have this kind of VM for one of this bytcode ? Is it hight level enougth like java byte code ? My second obvious question is about the bycode format, is it stable enought to concider using it as an 'archive' source/byte code ? Thanks for some guidances, before investing lots of energy ! Frank -------------- next part ------------...

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 (although not ideal) is to examine the source code. I believe llvm/lib/Bytecode/Reader is where you would want to start. If all you need to do is read LLVM bytecode, the bcread...

...just structs. This change doesn't really make LLVM IR higher-level in any way that would significantly affect the issues discussed in that thread. > > llvm has differents bytecode from low level, to more hight level... So do you see some interest to have this kind of VM for one of this bytcode ? > Is it hight level enougth like java byte code ? Java bytecode remains much much higher-level than LLVM IR; this hasn't significantly changed. > > My second obvious question is about the bycode format, is it stable enought to concider using it as an 'archive' source/byte...

A couple notes on this: 1. We also need to be able to *read* .o files for linking. Right now we just assume that any symbol not found in a bytcode file is implemented in some native library and will be resolved at runtime. This isn't the greatest assumption. To resolve native binary symbols we need to be able to read native .a, .so, and .o files to ensure the symbols are resolvable at runtime (or to actually resolve them if...

...bytecode in the file and just have the parts that are easy to represent as compileable in the main object sections. There is no intrinsic reason for all the runtime type information to get compiled into the core object module. Also I could bypass code thats difficult to compile and just stuff its bytcode into this section. So I think this really helps with partial compliation and supporting languags that have complex runtimes. The llvm bycode section would just get a stub runtime upcall for code that not compiled. For java for example this would probably be the compiled parts with stubs and a re...

...If you change the inclusion to > > include "../zlib/zlib.h" instead of just "zlib.h" in png.h > > then compilation succeeds. I haven't seen a reply to this on LLVM Dev, so I'm assuming it's been left unanswered. First, unless you want zlib and libpng as bytcode libraries, this error should not interfere with what you're doing (unless you're using the "make install" or "make install-bytecode" targerts, in which case use make -k to get over the errors). I imported these libraries because they're used by some of our favorite...

On Tue, 18 Jan 2005, John Cortes wrote: > Hi Chris, Hi! I'm CC'ing the llvmdev list for the benefit of others. > Since I see you're very involved in LLVM, I need a little guidance on getting > from C to MACH-SUIF. > > I've been given the task of using LLVM to translate C code to another VM > architecture known as MACH-SUIF. For this architecture, i don't

Well, I compiled release but it gave error while making png library. The inclusion of zlib.h in the file png.h cannot locate file zlib.h. If you change the inclusion to include "../zlib/zlib.h" instead of just "zlib.h" in png.h then compilation succeeds. regards,

Well, I compiled release but it gave error while making png library. The inclusion of zlib.h in the file png.h cannot locate file zlib.h. If you change the inclusion to include "../zlib/zlib.h" instead of just "zlib.h" in png.h then compilation succeeds. regards,

Hi Reid, Reid Spencer schrieb: > I have some thoughts on this too .. > Great! > On Fri, 2006-02-24 at 19:56 +0100, Jakob Praher wrote: > >>I get you 100 % here. But as you say later in the mail, many information >>is done by some runtime std::map<Value*,foo> stuff. Which is really >>handy at runtime, but I *had* serialization in mind when I was thinking

Specifically, the srcfile attribute of the srcref attribute of the two instances of the functions contain different environments, AFAICT. Environments are compared only by exact pointer, so this forces return FALSE. Snippets from .Internal(inspect(x)) and .Internal(inspect(y)): @cca008 03 CLOSXP g0c0 [MARK,NAM(2),ATT] FORMALS: @604b58 00 NILSXP g0c0 [MARK,NAM(2)] BODY: @cc9650 06 LANGSXP

On Sun, 4 Sep 2005, Tanu Sharma wrote: > > I have a doubt. > > This is an excerpt of the raw report I get after running Spec benchmarks > through llvm-test.I am trying to calculate the program execution > time.Does the output result in bold corresponds to "lli time" in > Makefile.spec ? I am not interested in llc, jit or cbe.I simply need the > normal

...> just have the parts that are easy to represent as compileable in the > main object sections. There is no intrinsic reason for all the runtime > type information to get compiled into the core object module. Also I > could bypass code thats difficult to compile and just stuff its > bytcode into this section. So I think this really helps with partial > compliation and supporting languags that have complex runtimes. > The llvm bycode section would just get a stub runtime upcall for code > that not compiled. > Hmm. Not sure I understand you 100 % here. I think the most i...

I have a doubt. This is an excerpt of the raw report I get after running Spec benchmarks through llvm-test.I am trying to calculate the program execution time.Does the output result in bold corresponds to "lli time" in Makefile.spec ? I am not interested in llc, jit or cbe.I simply need the normal bytecode and native code execution times after running my pass over them.I have modified

...get to a "once-and-done" solution on compilation. That is, a given module is compiled exactly once (per version). There's no such thing as "include" in XPL, only "import". The difference is that "import" loads the results of previous compilations (i.e. a bytcode file). I included it in my list because I thought it would be something quite handy for other source languages (Java would need it, for example). The functionality is something like Java's class loader except its a module loader for LLVM and it doesn't load the function bodies. > &gt...

Thanks Duncan It was really helpful. Regards Abdul On Fri, Jun 8, 2012 at 7:23 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi, > > >> If I compile the program using the following command line i.e. >> >> $ clang -O3 -lm *.c > > > this may be doing link time optimization. > > >> >> then >> >> $ time ./a.out >>

On Tue, 6 Jan 2004, Reid Spencer wrote: > A while back I promised to provide some feedback on useful extensions to > LLVM to better support source language writers (i.e. those _using_ LLVM, > not developing it). Below is a list of the ideas I've come up with so > far. Cool! Ideas are alway welcome! > If you respond to this, please respond to each item in a separate >

Hi, > If I compile the program using the following command line i.e. > > $ clang -O3 -lm *.c this may be doing link time optimization. > > then > > $ time ./a.out > > real 0m2.606s > user 0m2.584s > sys 0m0.012s > > BUT, if I use all the optimizations enabled with -O3 but specify them > explicity i.e. you can just use "opt -O3"

Hello I need some help here please. If we compile source files directly in to native code: $ clang -O3 -lm *.c then the runtime is like following real 0m2.807s user 0m2.784s sys 0m0.012s and If we emit LLVM bytcode and apply optimizations $ clang -O3 -c -emit-llvm *.c $ llvm-link *.o -o comb.ll $ time lli ./comb.ll then the runtime is real 0m2.671s user 0m2.640s sys 0m0.020s But, if I convert this same file comb,ll in to native binary $ clang comb.ll and execute it, then the runtime increases alot $ t...