<html>
<head>
<base href="https://bugs.llvm.org/">
</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 - Reduce the size of the coverage mapping section"
href="https://bugs.llvm.org/show_bug.cgi?id=33499">33499</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Reduce the size of the coverage mapping section
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>LLVM Codegen
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>vsk@apple.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Binaries produced with -fcoverage-mapping enabled tend to have very large
coverage mapping sections. For LLVM tools, they are in the hundreds of
megabytes range. One factor is that multiple copies of the same source mappings
are emitted into binaries (e.g from headers). We should investigate any other
contributing factors, and see what can be done to reduce the size of this
section.
Note that coverage mapping data is highly compressible. E.g extracting the
coverage section from llc and compressing it with gzip gives a 50% size
reduction. However, compressing coverage mappings on a per translation unit
basis is not a win.</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>