[llvm-commits] [PATCH] MCAssembler Performance: Lazy invalidation

Rafael Ávila de Espíndola rafael.espindola at gmail.com
Tue Dec 14 22:24:45 PST 2010


On 10-12-14 9:25 PM, David Meyer wrote:
>     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.
>
>
> 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.

Exactly, the bug is PR8467 is that we don't consider that things can get 
better when we relax. With your patch it would just be a bit more likely 
that we would hit it. Fixing the original issue in PR8467 should fix 
this too.


>     I have it too. Would you mind including the update to
>     test/MC/MachO/relax-recompute-align.s in this patch?
>
>
> 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.

How about adding a FIXME? Maybe add a pointer to PR8467.

>     *) Can you try your patch in the .s testcase in PR8711?
>
>
> There is no statistically significant effect on assemble time of this
> example. The output is also identical.
>
>
>     *) If this patch gives you a nice speed up in the attached test and
>     doesn't slow down the one in 8711, commit it.
>
>
> It doesn't affect 8711. My tests show this is more of an issue on
> X86-32. Have you tried to assemble contrived.s?
>
> 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.
>
> (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
> 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>,
> the rise is switching to llvm-mc, and the fall is applying this patch)

Yes, I understand the problem and how your patch fixes it. I was just a 
bit afraid if it would have bad effects on other tests by causing more 
layout passes. Since it doesn't, LGTM.

> Thanks,
> - David Meyer
>
>

Cheers,
Rafael



More information about the llvm-commits mailing list