<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 13, 2015 at 6:11 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Feel free to add this sort of thing to a TODO list of interesting things to<br>
> look at in the future, but please avoid doing<br>
> microoptimization-without-a-measured-performance-benefit until we have a<br>
> working linker (and then, hopefully dropping the<br>
> "without-a-measured-performance-benefit"). Almost every single one of these<br>
> "NFC" patches are stepping on Michael's toes and holding up real "FC"<br>
> patches that are what we need to get a working linker.<br>
<br>
<br>
</span>That is the kind of behavior that landed us on the old lld.</blockquote><div><br></div><div>Reality check: the old LLD was not slow due to lack of microoptimizations.</div><div><br></div><div>-- Sean Silva</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> We are<br>
building this one for performance from the start. Building something<br>
that we know is slower first just means we get to build it twice. Lets<br>
not do it three times.<br>
<br>
This patches are also the ones that allowed the creation of the string<br>
table as a regular output section and are on they way of getting a<br>
symbol table.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>