[LLVMdev] some llvm/clang missed optimizations

[Eli Friedman]

On Tue, Jan 26, 2010 at 12:36 PM, John Regehr <regehr at cs.utah.edu> wrote:
> 2.
> Sometimes not:
>
> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/EC/ECC74C0C.shtml

The primary issue here is that scalar evolution doesn't know how to
deal with loops using "sle" for the exit condition.  Shouldn't be too
hard to fix now that we have overflow flags for addition.

> 3.
>
> Repetitive code with lots of bitwise operations is compiled by LLVM into
> much larger code than the other compilers:
>
> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/ED/ED37DAF5.shtml
> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/1F/1F4003C7.shtml
>
> 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.

This looks like a one-off case; instcombine destroys the symmetry of
the code that the test harness duplicated by reducing the masking
constants.  Probably too complicated for too little gain to be worth
pursuing.

> 5.
>
> Sometimes a function modifies globals but even so has no net effect:
>
> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/8A/8AB0B238.shtml
> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/14/14157FE8.shtml
>
> Somehow gcc3 sees these but everyone else including gcc4 fails.
>
> 6.
>
> Here llvm-gcc and gcc, but not clang, exploit undefinedness of integer
> overflow to eliminate most of the code in a function:
>
> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/82/82A5CC31.shtml
>
> Most likely this is not what the authors of the code intended, but the
> compilers are correct.

LLVM doesn't handle correlated expressions at the moment.

-Eli