[llvm-bugs] [Bug 26346] New: IRLinker::stripNullSubprograms dominates the CPU profile

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=26346

            Bug ID: 26346
           Summary: IRLinker::stripNullSubprograms dominates the CPU
                    profile
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: krasin at google.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

I regularly profile linking Chrome with CFI (Control Flow Integrity, ) and in
the last time I spotted something new in the CPU profile:

+  19.16%        ld.gold  LLVMgold.so          [.] (anonymous
namespace)::IRLinker::stripNullSubprograms() [clone .isra.460]
+   4.41%        ld.gold  libc-2.19.so         [.] _int_malloc
+   4.21%        ld.gold  [kernel.kallsyms]    [k] 0xffffffff8172c822
+   2.49%        ld.gold  LLVMgold.so          [.]
llvm::NamedMDNode::getOperand(unsigned int) const
+   1.71%        ld.gold  libc-2.19.so         [.] malloc_consolidate
+   1.26%        ld.gold  libc-2.19.so         [.] _int_free
+   1.02%        ld.gold  LLVMgold.so          [.]
llvm::Value::assertModuleIsMaterialized() const
+   1.02%        ld.gold  LLVMgold.so          [.]
llvm::SelectionDAG::Combine(llvm::CombineLevel, llvm::AAResults&,
llvm::CodeGenOpt::Level)
+   0.94%        ld.gold  LLVMgold.so          [.]
llvm::PMDataManager::findAnalysisPass(void const*, bool)
+   0.91%        ld.gold  libc-2.19.so         [.] memset
+   0.84%        ld.gold  LLVMgold.so          [.]
llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*, unsigned char const*,
unsigned int)
+   0.77%        ld.gold  LLVMgold.so          [.] llvm::sys::MemoryFence()
+   0.75%        ld.gold  LLVMgold.so          [.]
llvm::SmallPtrSetImplBase::FindBucketFor(void const*) const
+   0.60%        ld.gold  LLVMgold.so          [.]
llvm::ReplaceableMetadataImpl::get(llvm::Metadata&)
+   0.59%        ld.gold  libc-2.19.so         [.] malloc
+   0.56%        ld.gold  LLVMgold.so          [.]
llvm::StringMapImpl::LookupBucketFor(llvm::StringRef)
+   0.53%        ld.gold  LLVMgold.so          [.]
llvm::MCExpr::evaluateAsRelocatableImpl(llvm::MCValue&, llvm::MCAssembler
const*, llvm::MCAsmLayout const*, llvm::MCFixup const*,
llvm::DenseMap<llvm::MCSecti
+   0.50%        ld.gold  LLVMgold.so          [.]
llvm::BitstreamCursor::readRecord(unsigned int, llvm::SmallVectorImpl<unsigned
long>&, llvm::StringRef*)
+   0.50%        ld.gold  LLVMgold.so          [.]
llvm::PMDataManager::removeNotPreservedAnalysis(llvm::Pass*)

stripNullSubprograms is fairly new (introduced in
http://reviews.llvm.org/rL256003) and based on the quick look could be made
faster / avoided alltogether (not 100% sure about the latter).

It would be nice to get rid of this unnecessary slowdown. It seems that the
performance is hit due to a lot of cache misses, which happens because
stripNullSubprograms accesses every single DISubprogram, and at this point this
data is not in L2 cache anymore. If this is done earlier, it could be 10000
times faster (this is the ratio between findNeededSubprograms and
stripNullSubprograms).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160127/1e7125b8/attachment-0001.html>