<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none"><!--P{margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>>Hi Alexey,</p>
<div style="color: rgb(33, 33, 33);">
<div>
<div>
<div dir="ltr"><br>
<div>Hi James, Thank you for your comments. Please, find my answers below:<br>
</div>
<div><br>
</div>
<div>>Regarding the link performance timings, have you tried profiling to see if there are any obvious performance >improvements that could be made? A slow down of 7x seems like an awfully large amount given what this >should be doing after all.
</div>
<div><br>
</div>
<div>I do not see "easy to fix" alternatives. But there are some posibilities to improve performance:<br>
<br>
1. ~10% improvement could probably be achieved by optimizing string pools </div>
<div>   (NonRelocatableStringpool/DwarfStringPool). </div>
<div><br>
</div>
<div>   Measurements show that it is spent ~10 sec in llvm::StringMapImpl::LookupBucketFor(). The problem
</div>
<div>   is that the same strings, again and again, are added to the string pool. Two attributes
</div>
<div>   having the same string value would be analyzed (hash calculated) and searched inside
</div>
<div>   the string pool. Even if these strings are already in string table(DW_FORM_strp, DW_FORM_strx).
</div>
<div>   The process could be optimized for string tables. So that if some string from the string table were
</div>
<div>   accessed previously then, it would keep a reference into the string pool. This would eliminate
</div>
<div>   a lot of string pool searches.  <br>
<br>
2. ~20-30% improvement by processing each object file in parallel.</div>
<div><br>
   Currently, all object files are analyzed sequentially and cloned sequentially.
<br>
   Cloning is started in parallel with analyzing. That scheme could be changed: </div>
<div>   analyzing and cloning could be done in parallel for each object file.<br>
   That requires refactoring of DWARFLinker and making string pools and DeclContextTree<br>
    thread-safe.<br>
<br>
3. ~10-20% improvement by support type units.<br>
<br>
   Currently, dsymutil/DWARFLinker does not support type units. If type units would be supported, then the "analyzing" step could be skipped for significant part of debug info data. This would save time.<br>
<br>
4. ~2-3% improvement could probably be achieved by optimizing DWARF parser classes.<br>
   Following is a list of ideas:<br>
   <br>
   https://reviews.llvm.org/D78672#inline-720056 <br>
   https://reviews.llvm.org/D78672#2000012<br>
   https://reviews.llvm.org/D78672#2000363.<br>
</div>
<div><br>
</div>
<div>>Also, do you have an idea whether the slow down is exponential for the size/linear etc?</div>
<div><br>
</div>
<div>It is linear. Following is the data for different runs(Output size is the size of overall binary) :</div>
<div><br style="font-family: "Courier New", monospace;">
<span style="font-family: "Courier New", monospace;">---------------------------------------</span><br style="font-family: "Courier New", monospace;">
<span style="font-family: "Courier New", monospace;">| linking time, sec | Output size, MB |
</span><br style="font-family: "Courier New", monospace;">
<span style="font-family: "Courier New", monospace;">---------------------------------------</span><br style="font-family: "Courier New", monospace;">
<span style="font-family: "Courier New", monospace;">|         4         |        64       |</span><br style="font-family: "Courier New", monospace;">
<span style="font-family: "Courier New", monospace;">|         5         |        79       |</span><br style="font-family: "Courier New", monospace;">
<span style="font-family: "Courier New", monospace;">|        18         |       211       |</span><br style="font-family: "Courier New", monospace;">
<span style="font-family: "Courier New", monospace;">|        25         |       308       |</span><br style="font-family: "Courier New", monospace;">
<span style="font-family: "Courier New", monospace;">|        29         |       356       |</span><br style="font-family: "Courier New", monospace;">
<span style="font-family: "Courier New", monospace;">|        51         |       526       |</span><br style="font-family: "Courier New", monospace;">
<span style="font-family: "Courier New", monospace;">|        72         |       788       |</span><br style="font-family: "Courier New", monospace;">
<span style="font-family: "Courier New", monospace;">---------------------------------------</span><br>
</div>
<div><br>
</div>
<div>>The problem is that if it is opt-in, but the link time cost is so high, it may put people off ever enabling it, which >would be a shame, as the debugger load time improvements seem worthwhile having.</div>
<div><br>
</div>
<div>From the other side - integrating of D74169 allows to make things iteratively. Doing above performance optimizations would require significant time. Implementing support of DWARF5 would probably require significant time. It would be much longer to implement
 whole thing at a time. Also, if D74169 would be integrated then additional people could probably join that work. I think LLVM developer policy encourages splitting some work on smaller pieces and iteratively integrate them.<br>
</div>
<div><br>
</div>
<div>Thank you, Alexey.<br>
</div>
<div><br>
</div>
<div>>James<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, 8 May 2020 at 14:18, Alexey Lapshin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr" style="font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255); font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Folks, we work on optimization of binary size and improvement of debug info quality.<br>
To reduce the size of the binary we use -ffunction-sections so that unused code would be garbage collected.
<br>
When the linker does garbage collection, a lot of abandoned debug info is left behind.
<br>
Besides inflated debug info size, we ended up with overlapping address ranges and no way to say valid vs garbage ranges(D59553).
<br>
To resolve these two problems, we use implementation extracted from dsymutil <a href="https://reviews.llvm.org/D74169" target="_blank">
https://reviews.llvm.org/D74169</a>.<br>
It adds --gc-debuginfo command line option to the linker to remove obsolete debug info.<br>
Currently, it has the following limitations: does not support DWARF5, modules, -fdebug-types-section, type units, .debug_types, multiple .debug_info sections, split DWARF, thin lto.<br>
<br>
Following are size/performance results for the D74169:<br>
<br>
<span style="font-family:"Courier New",monospace">A: --function-sections --gc-sections</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">B: --function-sections --gc-sections --gc-debuginfo</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">C: --function-sections --gc-sections --fdebug-types-section</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">D: --function-sections --gc-sections --gsplit-dwarf</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">E: --function-sections --gc-sections --gc-debuginfo --compress-debug-sections=zlib</span><br style="font-family:"Courier New",monospace">
<br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">LLVM code base:</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">--------------------------------------------------------------</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">| Options |    build time   |    bin size   |    lib size    |
</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">--------------------------------------------------------------</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">|    A    |    54min(100%)  |   19.0G(100%) |  15.0G(100.0%) |</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">--------------------------------------------------------------</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">|    B    |    65min(120%)  |    9.7G( 51%) |  12.0G( 80.0%) |</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">--------------------------------------------------------------</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">|    C    |    53min( 98%)  |   12.0G( 63%) |  15.0G(100.0%) |</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">--------------------------------------------------------------</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">|    D    |    52min( 96%)  |   12.0G( 63%) |   8.2G( 55.0%) |</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">--------------------------------------------------------------</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">|    E    |    64min(118%)  |    5.3G( 28%) |  12.0G( 80.0%) |</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">--------------------------------------------------------------</span><br style="font-family:"Courier New",monospace">
<br style="font-family:"Courier New",monospace">
<br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">Clang binary:</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">-------------------------------------------------------------</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">| Options |      size      |     link time  |  used memory  |</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">-------------------------------------------------------------</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">|    A    |    1.50G(100%) |    9sec(100%)  |  9307MB(100%) |</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">-------------------------------------------------------------</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">|    B    |    0.76G( 50%) |   68sec(755%)  | 15055MB(161%) |</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">-------------------------------------------------------------</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">|    C    |    0.82G( 54%) |    8sec( 89%)  |  8402MB( 90%) |</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">-------------------------------------------------------------</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">|    D    |    0.96G( 64%) |    6sec( 67%)  |  4273MB( 46%) |</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">-------------------------------------------------------------</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">|    E    |    0.43G( 29%) |   77sec(855%)  | 15000MB(161%) |</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">-------------------------------------------------------------</span><br style="font-family:"Courier New",monospace">
<br style="font-family:"Courier New",monospace">
<br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">lldb loading time:</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">--------------------------------------------</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">| Options |      time     |   used memory  |</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">--------------------------------------------</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">|    A    |  6.4sec(100%) |  1495MB(100%)  |</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">--------------------------------------------</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">|    B    |  4.0sec( 63%) |   826MB( 55%)  |</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">--------------------------------------------</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">|    C    |  3.7sec( 58%) |   877MB( 59%)  |</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">--------------------------------------------</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">|    D    |  4.3sec( 67%) |  1023MB( 69%)  |</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">--------------------------------------------</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">|    E    |  2.1sec( 33%) |   478MB( 32%)  |</span><br style="font-family:"Courier New",monospace">
<span style="font-family:"Courier New",monospace">--------------------------------------------</span><br>
<br>
I want to discuss the results and to decide whether it is worth to integrate of D74169:<br>
<br>
improvements:<br>
<br>
1. Reduces the size of debug info(50%).<br>
2. Resolves overlapping of address ranges(D59553).<br>
3. Reduced size of debug info allows tools to work faster and to require less memory.<br>
<br>
drawbacks and not implemented features:<br>
<br>
1. linking time is increased(755%).<br>
<br>
  The --gc-debuginfo option is off by default. So it would affect only those who need it and explicitly specified it.<br>
<br>
  I think the current DWARFLinker code could be optimized more to improve performance results.<br>
<br>
2. Support of type units.<br>
<br>
  That could be implemented further.<br>
<br>
3. DWARF5. <br>
<br>
   Current DWARFEmitter/DWARFStreamer has an implementation for DWARF generation, which does not support
<br>
DWARF5(only debug_names table). At the same time, there already exists code in CodeGen/AsmPrinter/DwarfDebug.h,
<br>
which implements most of DWARF5. It seems that DWARFEmitter/DWARFStreamer should be rewritten using
<br>
DwarfDebug/DwarfFile. Though I am not sure whether it would be easy to re-use DwarfDebug/DwarfFile.
<br>
It would probably be necessary to separate some intermediate level of DwarfDebug/DwarfFile.<br>
<br>
4. split DWARF support.<br>
<br>
   This solution does not work with split DWARF currently. But it could be useful for the split dwarf in two ways:<br>
<br>
   a) The generation of skeleton file could be changed in such a way that address ranges pointing to garbage
<br>
collected code would be replaced with lowpc=0, highpc=0. That would solve the problem of overlapping address
<br>
ranges(D59553). <br>
<br>
   b) The approach similar to dsymutil implementation could be used to generate monolithic debuginfo created
<br>
from .dwo files. That suggestion is from - <a href="https://reviews.llvm.org/D74169#1888386" target="_blank">
https://reviews.llvm.org/D74169#1888386</a>.<br>
      i.e., DWARFLinker could be taught to generate the same output as D74169 but for split DWARF as the source.<br>
<br>
5. -fmodules-debuginfo<br>
<br>
   That problem was described in this review - <a href="https://reviews.llvm.org/D54747#1505462" target="_blank">
https://reviews.llvm.org/D54747#1505462</a> . Currently, DWARFLinker/dsymutil has the same problem. It could be solved using the fact that DWARFLinker analyzes debuginfo. It could recognize debug info generated for the module and keep it(compile units containing
 debug info for modules do not have low_pc, high_pc).<br>
<br>
6. -flto=thin<br>
<br>
   That problem was described in this review <a href="https://reviews.llvm.org/D54747#1503720" target="_blank">
https://reviews.llvm.org/D54747#1503720</a>. It also exists in current DWARFLinker/dsymutil implementation. I think that problem should be discussed more: it could probably be fixed by avoiding generation of such incomplete declaration during thinlto, or, alternatively,
 DWARFLinker could recognize such situation and copy missed type declaration.<br>
<br>
=======================================================================================<br>
<br>
Debuginfo, Linker folks, What do you think about current results and future directions?</p>
<p><br>
It introduces quite a significant linking time increase(6x-8x). But it would affect only those who use that feature.</p>
<p>Thus the users will be able to decide whether that linking time increase is acceptable or not.<br>
Resolving all 1-6 points is quite a significant work. But, in the result, debug info is more correct and compact.<br>
<br>
Do you think that it would be good to integrate it and to start to work on improving?<br>
<br>
</p>
<p class="MsoNormal"><font size="1"><span style="font-size:11pt; font-family:"Trebuchet MS",sans-serif; color:black">Thank you, Alexey.<br>
</span></font></p>
<div id="gmail-m_-4760582018304110136Signature">
<div name="divtagdefaultwrapper">
<table cellpadding="0" border="0">
<tbody>
<tr>
<td style="padding:0.75pt" valign="top"><br>
</td>
<td style="padding:0.75pt"><br>
</td>
</tr>
</tbody>
</table>
<br>
<font size="2"><span style="font-size:11pt; font-family:"Trebuchet MS",sans-serif; color:black"></span></font></div>
</div>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>