<html>
<head>
<base href="https://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - IRLinker::stripNullSubprograms dominates the CPU profile"
href="https://llvm.org/bugs/show_bug.cgi?id=26346">26346</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>IRLinker::stripNullSubprograms dominates the CPU profile
</td>
</tr>
<tr>
<th>Product</th>
<td>new-bugs
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>krasin@google.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>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
<a href="http://reviews.llvm.org/rL256003">http://reviews.llvm.org/rL256003</a>) 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).</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>