
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=koi8-r">

<style type="text/css" style="display:none"><!-- p { margin-top: 0px; margin-bottom: 0px; } .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: 2px solid rgb(128, 0, 0); }--></style>

</head>

<body dir="ltr" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">

<p><span style="font-size: 10pt; color: rgb(33, 33, 33);">>On Thu, Oct 6, 2016 at 1:17 PM, George Rimar <grimar@accesssoftek.com> wrote:</span><br>

</p>

<div style="color: rgb(33, 33, 33);"><font size="2"><span style="font-size:10pt;">

<div class="PlainText">>>>There's an assertion here that the current implementation is not fast or<br>

>>> reusable. I'm not sure where that came from or what prompted it.<br>

>><br>

>>><br>

>>>Could you elaborate more on why you think these things?<br>

>>><br>

>>>-eric<br>

>><br>

>> I am not saying it is not reusable, but it definetely now do a bit more than<br>

>> we need in linker.<br>

>> Citation of myself from one of previous mails:<br>

>><br>

>> "short quick example:<br>

>> Imaging I want to get address ranges and so I want to use<br>

>> DWARFDebugInfoEntryMinimal::getAddressRanges(const DWARFUnit *U).<br>

>> For doing that I need DWARFUnit, which requires DWARFContext in constructor.<br>

>> Looking at comments that says<br>

>> "DWARFContextInMemory is the simplest possible implementation of a<br>

>> DWARFContext.", I am opening its constructor and<br>

>> see that it takes an object and do a scan over all sections uncompresses the<br>

>> compressed ones. But we do not need that as we already have<br>

>> content of sections available."<br>

>><br>

>> That this and possible other places need rework if we are want fastest<br>

>> solution for lld.<br>

>><br>

><br>

>I'm a little bit skeptical. It's not sure if the scan is a source of<br>

>significant slowdown at link-time (it could possibly be, but we don't<br>

>have the figures yet). Also, is there anything that prevents the API<br>

>in LLVM to be changed so that the performance hit (if any) can be<br>

>avoided? I'd rather try going that route, if possible.<br>

><br>

>--<br>

>Davide<br>

</div>

<div class="PlainText"><br>

</div>

<div class="PlainText">It is not just scan. It uncompresses sections, what I think we do not need in linker as we should have them uncomressed already.<br>

</div>

<div class="PlainText">Then it tries to proccess relocations for many debug sections, what is also seems excessive for gdb_index section build needs.<br>

<br>

</div>

<div class="PlainText">To clarify - I am not trying to say it is slow (I did not compare or run benchmarks and I am not really familar with it), but I guess it should be slower</div>

<div class="PlainText">than what I do in the patch just because it do a bit more job now. <span style="font-size: 10pt;">What sure </span><span style="font-size: 10pt;">can be changed.</span></div>

<div class="PlainText"><br>

</div>

<div class="PlainText">So Eric, David, if you guys think it is better to reimplement patch to reuse existent API - I think I am ready to try that.<br>

</div>

<div class="PlainText">If we can land patch as is and switch later - that also works for me.<br>

</div>

<div class="PlainText"><br>

</div>

<div class="PlainText">George.<br>

</div>

</span></font></div>

</body>

</html>