similar to: [LLVMdev] RE: is this code really JITed and/or optimized ? ..

Displaying 20 results from an estimated 4000 matches similar to: "[LLVMdev] RE: is this code really JITed and/or optimized ? .."

2004 Aug 14
1
[LLVMdev] is this code really JITed and/or optimized? ..
ick! Is there a bugzilla on this? Reid. On Sat, 2004-08-14 at 13:49, Chris Lattner wrote: > If you look at the 3 lines above the assert that is failing, you'll see > this: > > // FIXME: This code should handle a couple of common cases efficiently, but > // it should also implement the general case by code-gening a new anonymous > // nullary function to call.
2004 Aug 14
0
[LLVMdev] is this code really JITed and/or optimized? ..
On Sat, 14 Aug 2004, Valery A.Khamenya wrote: > > > ExecutionEngine* EE = ExecutionEngine::create( MP, true ); > > As Reid pointed out, changing true to false will get it to work. > > as I've posted already, I got Segmentation Fault. > Now, i have re-compiled LLVM with debug support. > > The evaluation is broken at line 78 in file: >
2004 Aug 16
0
[LLVMdev] cvsweb content is out-of-date
> If you have any more problems with this, please let me know! cvsweb content seems to be out-of-date: http://llvm.x10sys.com/cgi-bin/cvsweb.cgi/llvm/projects/ (the link to cvsweb is taken from llvm.org) -- Valery
2004 Aug 14
2
[LLVMdev] is this code really JITed and/or optimized? ..
> > ExecutionEngine* EE = ExecutionEngine::create( MP, true ); > > As Reid pointed out, changing true to false will get it to work. as I've posted already, I got Segmentation Fault. Now, i have re-compiled LLVM with debug support. The evaluation is broken at line 78 in file: lib/ExecutionEngine/JIT/JIT.cpp The assertion assert(ArgValues.size() == 1); fails. But
2004 Aug 13
0
[LLVMdev] is this code really JITed and/or optimized ? ..
On Sat, 14 Aug 2004, Valery A.Khamenya wrote: > (thanks to Reid, who gave nice advice) the fibonacci function code > works now. Please find attached file. > > but... the performance is adequate, say, for byte-code > interpretation mode and not for optimized JITing. > fibonacci function of 35 from attached file is more > then 100 times slower then the following code compiled
2004 Aug 13
3
[LLVMdev] is this code really JITed and/or optimized ? ..
Hi all, (thanks to Reid, who gave nice advice) the fibonacci function code works now. Please find attached file. but... the performance is adequate, say, for byte-code interpretation mode and not for optimized JITing. fibonacci function of 35 from attached file is more then 100 times slower then the following code compiled with "gcc -O2" : ----------- #include <iostream> int
2004 Aug 13
3
[LLVMdev] is this code really JITed and/or optimized ? ..
> If it's that slow, you're probably getting the interpreter instead of the > JIT. Try adding -print-machineinstr to the command line, or -debug, and > see what happens. If you're not getting the JIT, try stepping through the > LLVM program to see where it makes the execution engine and decides which > one to use... (thanks for quick reply) hm, here is the part of my
2004 Aug 13
0
[LLVMdev] is this code really JITed and/or optimized ? ..
On Sat, 14 Aug 2004, Valery A.Khamenya wrote: > hm, here is the part of my code starting LLVM function: > > /////////////////////////// > ExistingModuleProvider* MP = new ExistingModuleProvider(M); > ExecutionEngine* EE = ExecutionEngine::create( MP, true ); As Reid pointed out, changing true to false will get it to work. > // Call the `foo' function with no
2004 Aug 16
2
[LLVMdev] cvsweb content is out-of-date
And here's why: > rsync -az --delete --exclude='#*' --stats --bwlimit=256 rsync://llvm.cs.uiuc.edu/LLVM/ /home/llvm/cvs > rsync: failed to connect to llvm.cs.uiuc.edu: Connection refused > rsync error: error in socket IO (code 10) at clientserver.c(83) John, can you please look into this? Most likely the xinetd needs to be restarted.I'm not sure when it started failing,
2004 Aug 16
1
[LLVMdev] cvsweb content is out-of-date
Chris Lattner wrote: > On Mon, 16 Aug 2004, Reid Spencer wrote: > > >>That didn't fix it. Same problem. >> >>Perhaps rsyncd is not being run by xinetd? Can you see if its started? >>Check to see if there is a /etc/init.d/rsyncd file. If there is, and its >>not already running, try: >> /etc/init.d/rsyncd start >>otherwise: >>
2004 May 01
4
[LLVMdev] opt, llcc, ll++, -O1, -O2, -O3
Hi devels, there are two issues concerning invoking optimizations: 1. this document: http://llvm.cs.uiuc.edu/docs/GettingStarted.html is very nice, it would be good though to add in a section An Example Using the LLVM Tool Chain examples on optimization step. 2. If i am not wrong there is no tool, which integrates all steps: llvmgcc->opt->llc into something like llcc (and
2004 May 01
0
[LLVMdev] opt, llcc, ll++, -O1, -O2, -O3
On Sat, 1 May 2004, [koi8-r] "Valery A.Khamenya[koi8-r] " wrote: > there are two issues concerning invoking optimizations: > > 1. > this document: > http://llvm.cs.uiuc.edu/docs/GettingStarted.html > is very nice, it would be good though to add in a section > > An Example Using the LLVM Tool Chain > > examples on optimization step. That's an
2004 Apr 30
2
[LLVMdev] LLVM benchmarks against GCC
> The nightly tester is used for two purposes: making sure that nothing > breaks (the unit tests) and keeping tabs on how well performance is doing > (the spec and most multisource tests). It's not a reliable way to do > serious benchmarking, but can give good insights into where things can be > improved. hm, one day, the great benchmarking will be a reason to use LLVM, so, i
2004 Aug 16
0
[LLVMdev] cvsweb content is out-of-date
On Mon, Aug 16, 2004 at 09:56:57AM -0700, Reid Spencer wrote: > And here's why: > > > rsync -az --delete --exclude='#*' --stats --bwlimit=256 rsync://llvm.cs.uiuc.edu/LLVM/ /home/llvm/cvs > > rsync: failed to connect to llvm.cs.uiuc.edu: Connection refused > > rsync error: error in socket IO (code 10) at clientserver.c(83) > > John, can you please look
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
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 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
2010 Oct 26
3
[LLVMdev] Throwing C++ exception through LLVM JITed code
I am using LLVM to compile script code and then executing using the JIT compiler via the runFunction() method. The script code is contained with a C++ program compiled with G++. I am having a problem when an intrinsic function (i.e. a function implemented in C++ which is called from the LLVM compiled script) throws a C++ exception. I want the exception to be caught by the C++ code that invoked the
2006 Dec 06
1
Bug and patch for +terms with wildcards
In current Xapian SVN HEAD, there is a bug in the query parser concerned with the handling of wildcard terms with a "+" prefix. Specifically, a query such as "+foo* bar" will be parsed by the query parser into Xapian::Query("bar") if there are no terms in the database which start "foo". Instead, since the "+" term cannot be matched, I believe
2012 Jan 31
0
[LLVMdev] Generate backtrace info for JITed code
My app generates LLVM IR on the fly, JITs, and executes. It also has a backtrace printer installed as a signal handler, that prints a human-readable backtrace if the app crashes. Is there a succinct guide to exactly what I need to do to the LLVM IR I generate (or the calls I make to JIT) so that backtrace() and backtrace_symbols() (on Linux or OS X) can correctly print the call stack when a