search for: nullari

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

On Feb 11, 2010, at 2:54 PM, David Greene wrote: > > Is that basically right? So I would have to do this: > > %r8 = load <2 x double>* %r6, align 16, !nontemporal !0 > [...] > !0 = metadata !{ i32 1 } Yes. > I would really rather not have to specify the entirely redundant !0. Just the > fact that the instruction has metadata with index/name

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.

On Fri, Sep 5, 2008 at 8:26 PM, Jon Harrop <jonathandeanharrop at googlemail.com> wrote: > 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? What is the signature of the function you are

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

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

Hello, [Using LLVM r155315, according to `svn log | head`] I am experimenting with programatically building and jitting functions in a module, and I seem to be coming across a crash in some generated code. Using the llvm-c interface I build up the module which dumps like this: ; ModuleID = 'MyModule' target datalayout = "i686-apple-darwin11" target triple =

Hi David, I'm not certain, but to me the "LLVMSetTarget(module, "i686-apple-darwin11");" line looks suspicious. I'm not familiar with all the ins and outs of how target triples get handled, but it looks to me like that's requesting 32-bit code. I think that if you omit that line completely then the target will be inferred from the execution environment. My best

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

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

Hi everyone, This Fall has been busy, busy, busy. In addition to the usual LLVM hacking, our developers have been moving all over the country, starting classes, ending internships, getting married, and traveling the world. Despite all of the non-LLVM fun we've been having, we've managed to get some work done, too. :) Here is my traditional distillation of llvm-commits: New High-Level

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

Hi Andreas, First, thanks again for undertaking this work and submitting it back. There is a lot of good stuff here and it would be great to see it get back into the tree. I have a few major high-level comments on the patch. First off, the patch is quite large and should be broken down into separate incremental changes which are easier to review and apply. I think the patches should more or less

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

Hi Daniel, Daniel Dunbar wrote: > Hi Andreas, > > First, thanks again for undertaking this work and submitting it back. There is a > lot of good stuff here and it would be great to see it get back into the tree. Thanks for taking the time to review this, I know its a huge patch. I still have a few questions on how you would like this patch to be re-factored and split up. > [...]