[llvm-commits] Speeding up instruction selection

[Roman Levenstein]

Hi,

2008/4/23 Evan Cheng <evan.cheng at apple.com>:
> Very nice!

>  Please run it through MultiSource and SingleSource tests.
Will do.

>  Dan and I  will run it through External tests.
Very nice.

>  If it shows no regression and llvm- gcc bootstrapping works. Then please check it in.

Just to make it clear:
This patch is applied currently to the output of Tablegen.
But the proper patch will need to change the Tablegen to generate
correct *.inc files.
Thinking about it, I have a question:
Right now, the beginning of the generrated instruction selector files
is always the same, independent of the *.td file and target
architecture.
But it is generated by tablegen still and therefore cannot be
substituted easily, without changing the tablegen.
Question: May be it is better to define this common part in an include
file, e.g. ISelHeader.h, and then tablegen would generate only the
#include <llvm/CodeGen/ISelHeader.h> line. What do you think?

-Roman

>  On Apr 23, 2008, at 12:35 AM, Roman Levenstein wrote:
>
>  >
>  >
>  >> 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
>  >
>  >
>  > -Roman