[LLVMdev] some llvm/clang missed optimizations
regehr at cs.utah.edu
Tue Jan 26 12:36:25 PST 2010
A few random observations:
Clang could do better with large but boring switches like this:
Performance of clang's output will be fine but this is a major code size
Destruction of stupid loops is incomplete, sometimes due to phase
This is both a speed and size issue. Probably this kind of code most
often appears in machine-generated C or where loops contain logging code
that is conditionally compiled away.
Repetitive code with lots of bitwise operations is compiled by LLVM into
much larger code than the other compilers:
Note that this is straight-line code, so LLVM's output will run 4-5
times longer than everyone else's.
I'll be interested to learn the source of this one.
It seems possible to do a better job recognizing that the current stack
frame can be used unmodified by a new call:
This is a speed lose as well as size. This pattern seems quite common
in real code, due to layered APIs. Of course when IPO is on, most of
these calls should be destroyed.
Sometimes a function modifies globals but even so has no net effect:
Somehow gcc3 sees these but everyone else including gcc4 fails.
Here llvm-gcc and gcc, but not clang, exploit undefinedness of integer
overflow to eliminate most of the code in a function:
Most likely this is not what the authors of the code intended, but the
compilers are correct.
Cute elimination of useless varargs code:
More information about the llvm-dev