search for: nullary

...senting "alldocument" queries. Currently, a special query term can be created which matches all documents by creating a leaf query for which the term is the null string. This is a somewhat "magic" and unobvious approach - instead, we could introduce an "OP_MATCH_ALL" nullary operator, which would be converted to a postlist which matches all documents. It's not clear why an empty term should magically match all documents, rather than none, or indeed why it should have any special meaning. The patch includes test cases for the bug, fixes the problem, and I think is...

...etadata with index/name "nontemporal" should > be enough. Why? These are uniqued anyway, it won't matter for performance and "!nontermporal !0" is not substantially worse than "!nontermporal". I'd rather keep the metadata model simple than optimize it for nullary metadata. -Chris

...ris 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. > > Basically it's saying that we only support one argument functions that > take an integer right now. This is a bug/suboptimality, hence the FIXME. > > There are several different ways to fix the problem, as hinted at by the > comment. In the short term...

...bably the overhead you are seeing. There should be little more inherent overhead than the cost of a function call if the stub path isn't being taken. The simple solution (aside from fixing JIT) is to change your signature to match one of the ones the JIT special cases (see JIT::runFunction). A nullary one with arguments passed in globals works fine, if thread safety isn't a concern. - Daniel

...could make life > easier for other guys too. 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. Basically it's saying that we only support one argument functions that take an integer right now. This is a bug/suboptimality, hence the FIXME. There are several different ways to fix the problem, as hinted at by the comment. In the short term, adding something like this:...

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

I'm having another play with LLVM using the OCaml bindings for a forthcoming OCaml Journal article and I have a couple of remarks: Firstly, I noticed that the execute engine is very slow, taking milliseconds to call a JIT compiled function. Is this an inherent overhead or am I calling it incorrectly or is this something that can be optimized in the OCaml bindings? Secondly, I happened to

...f60c93808 If I use the debugger to poke 0x00007fff into the top half of rsp, stepping through works, and after one jump I get to my function; I see the mul and add instruction. Continuing to step, I need one more fixup of rsp (perhaps corresponding to two jitted functions: mine, and the auto-built nullary stub?) before returning to my main function. Is there anything obvious I've missed? Sorry for the long mail but I figure if I put all my data, then where I went wrong would be more obvious to someone who knows what they're doing :) Thanks, and please let me know if there's anything ex...

...f60c93808 If I use the debugger to poke 0x00007fff into the top half of rsp, stepping through works, and after one jump I get to my function; I see the mul and add instruction. Continuing to step, I need one more fixup of rsp (perhaps corresponding to two jitted functions: mine, and the auto-built nullary stub?) before returning to my main function. Is there anything obvious I've missed? Sorry for the long mail but I figure if I put all my data, then where I went wrong would be more obvious to someone who knows what they're doing :) Thanks, and please let me know if there's anything ex...

I 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. > Basically it's saying that we only support one argument functions that > take an integer right now. This is a bug/suboptimality, hence the > FIXME. Reid wrote: > ick! Is there a bugzilla on this? ... and filed PR419. Since then I've implemented the FIXME...

On Thursday 11 February 2010 16:31:16 Garrison Venn wrote: > I don't think the lang ref metadata grammar section > (http://llvm.org/docs/LangRef.html#metadata) has been fully updated with > how !dbg metadata is used in > http://llvm.org/docs/SourceLevelDebugging.html. At least to me it is not > clear. In my mind I translate the phrase "LLVM IR allows metadata to be >

I don't think the lang ref metadata grammar section (http://llvm.org/docs/LangRef.html#metadata) has been fully updated with how !dbg metadata is used in http://llvm.org/docs/SourceLevelDebugging.html. At least to me it is not clear. In my mind I translate the phrase "LLVM IR allows metadata to be attached to instructions " into a grammar depicted in SourceLevelDebugging.html. I

...ous Changes: 27. John fixed the configure script so that you shouldn't have to rebuild all of LLVM after a change to config.h (usually just lib/System). 28. The JIT interfaces have been enhanced to allow C++ code to JIT and call any LLVM function (previously only 'main' and nullary functions were really supported). 29. Bill Wendling contributed a patch that enables the C backend to emit NAN and +/- infinity global variable initializers (PR33). 30. llvm-test now includes benchmarks from the Prolangs-C and Prolangs-C++ suites. 31. Reid added further optimizati...

It surprised me that prod(numeric(0)) is 1. I guess if you say (operation(nothing) == identity element) this makes sense, but ?? Looking in the code, this makes sense: basically (s=1; for i=0 to length(x), multiply s by x[i]) -- which comes out to 1. What *should* prod(numeric(0)) produce? I couldn't find the answer documented anywhere. (And how about sum(numeric(0))==0, which for

...;<<((*ei).first?(*ei).first->getName():"0")<<","; > + cerr<<(*ei).second->getName()<<")"; > + } > + cerr<<"}\n"; > + } > + }; To be more in line with LLVM I would recommend making this a nullary const method on the MST, and rename it to dump. Also, please use Support/raw_ostream.h for output instead of C++ iostreams. > --- llvm-van/include/llvm/Analysis/Passes.h 2009-06-29 13:49:13.000000000 +0200 > +++ llvm-c7/include/llvm/Analysis/Passes.h 2009-06-26 16:48:02.000000000 +0200...

Hi all, as proposed in http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/020396.html I implemented the algorithm presented in [Ball94]. It only instruments the minimal number of edges necessary for edge profiling. The main changes introduced by this patch are: *) a interface compatible rewrite of ProfileInfo *) a cleanup of ProfileInfoLoader (some functionality in ProfileInfoLoader

...rst->getName():"0")<<","; >> + cerr<<(*ei).second->getName()<<")"; >> + } >> + cerr<<"}\n"; >> + } >> + }; > > To be more in line with LLVM I would recommend making this a nullary const > method on the MST, and rename it to dump. Also, please use Support/raw_ostream.h > for output instead of C++ iostreams. Okay. > >> --- llvm-van/include/llvm/Analysis/Passes.h 2009-06-29 13:49:13.000000000 +0200 >> +++ llvm-c7/include/llvm/Analysis/Passes.h 2009-0...