[llvm-commits] Speeding up instruction selection

[Dan Gohman]

Hi Roman,

On Wed, April 23, 2008 12:35 am, Roman Levenstein wrote:
> Hi Dan,
>
> 2008/4/23, Dan Gohman <gohman at apple.com>:
>>
>>  Do you see any compile-time difference between using a std::set
>>  queue and the NO_QUEUE approach, out of curiosity?
>
> Well, the difference between using a std::set queue and the NO_QUEUE
> approach is rather small, especially on small and medium-sized
> testcases. I have the impression that it comes mainly from the fact
> that NO_QUEUE does not do any dynamic heap memory allocation. Both of
> these approaches are significantly faster than the current
> heap-sorting approach.

Judging by your numbers below, overall compilation of Kimwuitu
with NO_QUEUE is 9% faster than with std::set. Even if we're
talking about larger-than-usual BBs resulting from LTO, that's
a pretty big number.

>
>
>>  In addition to regular testing, since this patch doesn't modify any
>>  heuristics, it should be possible to compare assembly output
>>  between an unmodified compiler and one with this patch applied.
>>  Can you verify that this patch doesn't change any output on some
>>  interesting testcases?
>
> I tried it with Kimwitu, which is a very big and complex test-case.
> All approaches produce exactly the same assembler code. On my
> test-cases with very big BBs it also produces exactly the same
> results.
>
> For the sake of comparison, here are also some time statistics for the
> compilation of Kimwitu, measured by means of the Linux "time" command:
>
> Current LLVM approach:
> real    1m51.464s
> user    1m21.161s
> sys     0m8.529s
>
> std::set approach:
> real    1m37.938s (13% faster than current LLVM implementation)
> user    1m16.169s
> sys     0m7.732s
>
> NO_QUEUE approach:
> real    1m29.548s (20% faster than current LLVM implementation)
> user    1m14.949s
> sys     0m7.824s

This looks really good. Could you run a few other codes to
help verify that Kimwitu isn't an anomaly?

Thanks,

Dan