search for: at_end

...Builder.new()). Uninitialized builders are very dangerous (they leak instructions if you use them), so you might want to add overloads for new in order to avoid boilerplate code. > It can be positioned using the methodsposition(block, instr=None), > position_before(instr) and position_at_end(block). There's an "IR navigator" concept you can implement to avoid writing so many overloads here. It provides a complete "position" or "iterator" concept. It's not entirely explicit in the C bindings—it would be memory-inefficient if it were. But you...

Hi all, I'd like to announce the availability of Python bindings for LLVM. It is built over llvm-c, and currently exposes enough APIs to build an in-memory IR (and dump it!). It needs LLVM 2.3 latest and Python 2.5 (2.4 should be sufficient, but I haven't tested). Tested only on Linux/i386. Would love to hear your comments. [Needless to say, it's all work in progress, but mostly it

...nal::RefCntPtr<ChertDatabase const>) const 5402 2.0023 ChertPostList::jump_to(unsigned int) 4518 1.6746 ChertPostList::skip_to(unsigned int, double) 4341 1.6090 ChertPostList::next_in_chunk() 4207 1.5594 ChertPostList::get_docid() const 4065 1.5067 ChertPostList::at_end() const 3988 1.4782 AndMaybePostList::at_end() const 3899 1.4452 OrPostList::get_docid() const 3655 1.3548 MultiMatch::get_mset(unsigned int, unsigned int, unsigned int, Xapian::MSet&, Xapian::Weight::Internal const&, Xapian::MatchDecider const*, Xapian::MatchDecider cons...

...588 #2 0x084c0c5c in make_decl_rtl (decl=0xb7b9d618) at ../../2006-03-14-llvm-gcc-4/gcc/varasm.c:1018 #3 0x084c8207 in assemble_alias (decl=0xb7b9d618, target=0xb698fe00) at ../../2006-03-14-llvm-gcc-4/gcc/varasm.c:4765 #4 0x084d05e6 in rest_of_decl_compilation (decl=0xb7b9d618, top_level=1, at_end=0) at ../../2006-03-14-llvm-gcc-4/gcc/passes.c:204 Printing decl in frame 2 gives: (gdb) call debug_tree(decl) <function_decl 0xb7b9d618 _X_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv type <function_type 0xb7ab7e88 type <void_type 0xb7ab5b40 void sizes-gimplified...

...nstruction? Maybe it makes more sense to create it 'from' a block, something like: builder = basic_block_obj.builder() with it being positioned at the end of the block by default. But then, your ocaml syntax is much cleaner: > // At the start or end of a BB: > Builder.new(At_end bb) > Builder.new(bb.begin) > > // Before or after a given instruction: > Builder.new(Before instr) > Builder.new(instr.succ) so I'll see how this can be done a bit, ah, Pythonically. > Finally, just as the C++ STL has reverse_iterator, it did prove >...

Hi Everybody, Here is the first version of my match for an ExternalPostList, it should apply cleanly to 0.9.5 and 0.9.6. You can use it by first implementing an ExternalPostingSource, then creating a new Query object passing a reference an instance of your implementation to the constructor, see query.h. The ExternalPostingSource implementation is reference counted, so when its no

Evan Cheng wrote: > Hi, > > Here is the follow on patch for this problem. Please apply this from > the top of the tree and rebuild. With the patch from Chris and then the patch from you combined, the previous error disappeared, but I get another error, reduced to this: ./cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mtune=pentiumpro -auxbase-strip libgcc/./_clz.o -g -O2

...vert.cpp:3870 #4 0x00295d80 in TreeConstantToLLVM::ConvertArrayCONSTRUCTOR (exp=0x45e48d20) at ../../src/gcc/llvm-convert.cpp:4083 #5 0x0028b624 in emit_global_to_llvm (decl=0x45e4c700) at ../../src/gcc/llvm-backend.cpp:377 #6 0x00284844 in rest_of_decl_compilation (decl=0x45e4c700, top_level=0, at_end=0) at ../../src/gcc/passes.c:252 #7 0x002a7da8 in TreeToLLVM::EmitBIND_EXPR (this=0xbfffe63c, exp=0x45e4d5a0, DestLoc=0x0) at ../../src/gcc/llvm-convert.cpp:1119 #8 0x00297ac0 in TreeToLLVM::Emit (this=0xbfffe63c, exp=0x45e4d5a0, DestLoc=0x0) at ../../src/gcc/llvm-convert.cpp:474 #9 0x002882f0 i...

...t process_extent(struct send_ctx *sctx, goto out; ret = send_write_or_clone(sctx, path, key, found_clone); - + if (ret) + goto out; +out_hole: + ret = maybe_send_hole(sctx, path, key); out: return ret; } @@ -4181,6 +4307,19 @@ static int finish_inode_if_needed(struct send_ctx *sctx, int at_end) } if (S_ISREG(sctx->cur_inode_mode)) { + if (need_send_hole(sctx)) { + if (sctx->cur_inode_last_extent == (u64)-1) { + ret = get_last_extent(sctx, (u64)-1); + if (ret) + goto out; + } + if (sctx->cur_inode_last_extent < + sctx->cur_inode_size) { + ret...

...Perl_sv_catpvn_flags 0.03% /mnt/btr/public perl [.] memmove at plt 0.03% /mnt/btr/public perl [.] S_unshare_hek_or_pvn 0.03% /mnt/btr/public perl [.] Perl_pp_ref 0.03% script/public-i libxapian.so.30.8.0 [.] GlassPostList::at_end 0.02% script/public-i libxapian.so.30.8.0 [.] LeafPostList::get_weight 0.02% script/public-i libxapian.so.30.8.0 [.] Xapian::Internal::intrusive_ptr<GlassDatabase const>::~intrusive_ptr 0.02% script/public-i libxapian.so.30.8.0 [.] GlassPostList::skip_to 0.02% sc...

Going back to the "prioritizing aggregated DBs" thread from February 2020, I've got 390 Xapian shards for 130 public inboxes I want to search against(*). There's more on the horizon (we're expecting tens of thousands of public inboxes). After bumping RLIMIT_NOFILE and running ->add_database a bunch, the actual queries seem to be taking ~30s (not good :x). Now I'm