<div dir="ltr">I feel that discussing performance on the two-pass solution at this point could lead to a premature optimization> Maybe we should run a benchmark to see if it's going to be a real issue. Second sort can be faster than first sort because second sort sorts a mostly-sorted array. But sure, sort is O(log n). Run that stuff twice is not optimal. We may want to avoid that if possible.<div><br></div><div>I carefully read the code for ELF and found that the functionality that the LayoutPass provides is overkill for that architecture. We don't need that amount of code.</div><div><br></div><div>Currently the LayoutPass is applied unconditionally to all architectures. Maybe we should stop doing that and let each arch to define its own layout pass. The current LayoutPass can be simplified to <10 lines of code, so it wouldn't worth abstracting.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 27, 2015 at 4:21 PM, <a href="mailto:kledzik@apple.com">kledzik@apple.com</a> <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sure two passes is conceptually clean, but if it turns out that running sort() twice for mach-o makes linking slower for mach-o than it currently is, then that is not ideal.<br>
<br>
The other way would be to have one layout pass that uses a base class for the comparator which the ELF layout pass uses as-is, but there is a (non virtual) way for mach-o to supply a more complex comparator (today's comparator).<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<a href="http://reviews.llvm.org/D7212" target="_blank">http://reviews.llvm.org/D7212</a><br>
<br>
EMAIL PREFERENCES<br>
  <a href="http://reviews.llvm.org/settings/panel/emailpreferences/" target="_blank">http://reviews.llvm.org/settings/panel/emailpreferences/</a><br>
<br>
<br>
</div></div></blockquote></div><br></div>