<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Looks like this just makes PR8467 a bit more likely, no? That can/should probably be fixed differently, so I don't think it it is a big problem.</div>
<div class="im"><br></div></blockquote><div><br></div><div>The output of the example in PR8467 is the same. This patch makes it more likely that we'll relax when we don't have to, but only in the edge case where there's an align that shrinks and a relocation very near the 1-byte boundary.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I have it too. Would you mind including the update to test/MC/MachO/relax-recompute-align.s in this patch?<br>
<br></blockquote><div><br></div><div>Attached is a new patch which includes the altered test. However, I'm not sure the test is serving any purpose anymore... it was meant to test the align recompute behavior, which is no longer happening.</div>
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
*) Can you try your patch in the .s testcase in PR8711?<br></blockquote><div><br></div><div>There is no statistically significant effect on assemble time of this example. The output is also identical.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
*) If this patch gives you a nice speed up in the attached test and doesn't slow down the one in 8711, commit it.<br></blockquote><div><br></div><div>It doesn't affect 8711. My tests show this is more of an issue on X86-32. Have you tried to assemble contrived.s?</div>
<div><br></div><div>With the current invalidation method, the algorithm is O(n^2) in the number of fragments. If you have only a few hundred fragments, you won't notice a problem. But if you start having thousands or tens of thousands of fragments, things get slow fast.</div>
<div><br></div><div>(It was taking 3 minutes to assemble spec2k-gcc-nacl with llvm-mc vs. 2.5 seconds for nacl-gcc, until I made this change. See <a href="http://build.chromium.org/f/client/perf/nacl-lucid64-spec-x86/spec2k/report.html?history=150&rev=-1&graph=compiletime_gcc">http://build.chromium.org/f/client/perf/nacl-lucid64-spec-x86/spec2k/report.html?history=150&rev=-1&graph=compiletime_gcc</a>, the rise is switching to llvm-mc, and the fall is applying this patch)</div>
<div><br></div><div>Thanks,</div><div>- David Meyer</div><div><br></div><div><br></div></div>