search for: do_lookup_x

...ot; (just the lit run) in a BUILD_SHARED_LIBS build. The performance was almost identical, so I decided to try sysv versus gnu (both produced by lld). The results are interesting: % grep -v '^#' perf-gnu/perf.report-by-dso-sym | head 38.77% ld-2.24.so [.] do_lookup_x 8.08% ld-2.24.so [.] strcmp 2.66% ld-2.24.so [.] _dl_relocate_object 2.58% ld-2.24.so [.] _dl_lookup_symbol_x 1.85% ld-2.24.so [.] _dl_name_match_p 1.46%...

...3.0303 libLLVMCore.so std::vector<llvm::PassInfo const*, std::allocator<llvm::PassInfo const*> >::begin() const 1 1.5152 ld-2.19.so _dl_check_map_versions 1 1.5152 ld-2.19.so _dl_fixup 1 1.5152 ld-2.19.so do_lookup_x 1 1.5152 libLLVMAsmParser.so llvm::LLLexer::ReadString(llvm::lltok::Kind) 1 1.5152 libLLVMCodeGen.so llvm::MachineFunction::getName() const 1 1.5152 libLLVMCodeGen.so llvm::MachineOperand::isReg() const .... >From this you can see that lli is calling the...

...re.so std::vector<llvm::PassInfo > const*, std::allocator<llvm::PassInfo const*> >::begin() const > 1 1.5152 ld-2.19.so _dl_check_map_versions > 1 1.5152 ld-2.19.so _dl_fixup > 1 1.5152 ld-2.19.so do_lookup_x > 1 1.5152 libLLVMAsmParser.so > llvm::LLLexer::ReadString(llvm::lltok::Kind) > 1 1.5152 libLLVMCodeGen.so > llvm::MachineFunction::getName() const > 1 1.5152 libLLVMCodeGen.so llvm::MachineOperand::isReg() > const > .... > > From this yo...

Hi, Under linux a large portion of the profiling these days happens with perf, but there's no support for it from LLVM's JITs. For a while perf could associate address+size to symbols by writing a /tmp/perf-$pid.map file: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/tools/perf/Documentation/jit-interface.txt A year or so perf also gained the ability to actually

With the ATI bug I was hitting earlier fixed, only my btrfs partition continues to show high cpu usage for some operations. Rsync, git pull, git checkout and svn up are typicall operations which trigger the high cpu usage. As an example, this perf report is from using git checkout to change to a new branch; the change needed to checkout 208 files out of about 1600 total files. du(1) reports

...l - 93.41% lli jitted-27248-2.so [.] stupid_isprime stupid_isprime main llvm::MCJIT::runFunction llvm::ExecutionEngine::runFunctionAsMain main __libc_start_main 0xec26258d4c544155 + 0.55% lli ld-2.24.so [.] do_lookup_x + 0.22% lli ld-2.24.so [.] _dl_lookup_symbol_x + 0.17% lli [kernel.vmlinux] [k] unmap_page_range + 0.16% lli ld-2.24.so [.] _dl_fixup Instruction level view: │ Disassembly of section .text:...

...l [.] Perl_hv_common 0.24% perl perl [.] Perl_rpeep 0.24% script/public-i libxapian.so.30.8.0 [.] memcmp at plt 0.24% script/public-i libxapian.so.30.8.0 [.] Xapian::Weight::init_ 0.23% /mnt/btr/public ld-2.28.so [.] do_lookup_x 0.22% script/public-i libxapian.so.30.8.0 [.] read_start_of_chunk 0.22% /mnt/btr/public perl [.] sbox32_hash_with_state.constprop.8 0.22% /mnt/btr/public perl [.] S_scan_str 0.22% /mnt/btr/public perl [.] Perl_op_sibling_s...

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

...[.] stupid_isprime > stupid_isprime > main > llvm::MCJIT::runFunction > llvm::ExecutionEngine::runFunctionAsMain > main > __libc_start_main > 0xec26258d4c544155 > + 0.55% lli ld-2.24.so [.] do_lookup_x > + 0.22% lli ld-2.24.so [.] _dl_lookup_symbol_x > + 0.17% lli [kernel.vmlinux] [k] unmap_page_range > + 0.16% lli ld-2.24.so [.] _dl_fixup > > > Instruction level view: > >...

Having something like this available in tree would definitely be useful. For simplicity, why don't we start with support for the second style? This is the long term useful one and would be a good starting point for getting the code in tree. Can you give a pointer to the patch so that I can assess the rough complexity? If it's simple enough, I'd be happy to help get it reviewed