[LLVMdev] x86 cogen quality

[Finn S Andersen]

Hi, I have a question about x86 code quality.

I have run a few benchmarks and compared the
running time of executables created by LLVM to
executables created by gcc.

It appears that code generated by LLVM is x1.5 - x3
times slower than code generated by gcc, for the x86

For some of the benchmarks the linear scan regalloc
works. When it does, results are in the x1.0 - 1.5
range. Unfortunately, the linear scan allocator breaks
on most of my code.

Question:
1) Do my observations fit your general experience ?

I haven't looked into the details of the generated
x86 code. I have the following observation, though:

When using gcc as a backend (compiling to the 'c' target
and then recompiling with gcc) results are generally a lot
better than just using the LLVM->x86 backend. This
indicates that the performance difference is mostly
located to the LLVM->x86 backend. Further, for those
of my codes where the new allocator works, results are
much better. Whether this is due to the allocator, or
some interaction between it and cogen, I do not know.

Currently, I am just playing with LLVM, but the longterm
plan is to build a new backend for a new machine. It won't
be register starved as the x86 is.

Question:
2) Is there a similar performance differential between
    LLVM->sparc and gcc on sparc, or are they much closer
    because the sparc has more registers and thus should
    be less dependent on good register allocation ?

3) What is the expected timeframe for the new regalloc to
    become stable ? .. or perhaps I should make a more general
    question: what is the perceived status in terms of performance
    for the two compiler backends and for the compiler backend
    part of the infrastructure ?

Finally
I think LLVM looks *very* nice and appears to be a substantial
contribution to the world of open source compiler infrastructure.

Best regards, and thanks in advance,
/Finn