[LLVMbugs] [Bug 7168] New: Computed gotos and more

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=7168

           Summary: Computed gotos and more
           Product: new-bugs
           Version: 2.7
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Keywords: code-quality
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bearophile at mailas.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4903)
 --> (http://llvm.org/bugs/attachment.cgi?id=4903)
C source of the look and say sequence counter

Generally here when I report a performance problem I try to show a synthetic
benchmark, that is a minimal piece of code that makes it easy to spot where the
problem is. But while benchmarking LLVM 2.7 I have found two performance
problems that I am not able to locate in few lines of asm, so I have to show a
bit larger code example. This bug report is about one of those two problems.

This C benchmark is related to the Audioactive sequence:
http://en.wikipedia.org/wiki/Look-and-say_sequence

This program just prints the length of the strings up to a max iteration count,
very quickly. This is a reduced program, I have stripped out the not essential
parts.

This program contains a computed gotos, to improve its performance a little. I
have seen that LLVM 2.7 (llvm-gcc) is able to run this program faster than LLVM
2.6, thanks to the recent improvements in the implementation of computed gotos.

But there is a significant performance gap still between GCC and llvm-gcc.

I have compiled the code with just, on a 32 bit Windows system:
-O3 -s

Timings, N=71 (output redirected to file), seconds:
  llvm-gcc: 3.88
  gcc:      2.46


In this program GCC uses this instruction to implement the computed goto:
jmp *-232(%ebp,%ecx,4)

but even replacing the computed goto with a normal switch and compiling the
program again with both llvm-gcc and gcc shows that some performance difference
persists (but it's lower), so probably this performance problem is not all in
the computed goto implementation.

This benchmark is also interesting because it's a minimal example of a common
class of programs, that simulate finite state machines using the CPU program
counter for max performance.

This program can be used for benchmarks and tests of llvm.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.