[PATCH] IndVarSimplify : do not recompute an IV value used outside of the loop if it is trivially known not to be beneficial

[Andrew Trick]

On Feb 28, 2013, at 2:15 AM, Arnaud A. de Grandmaison <arnaud.adegm at gmail.com> wrote:

> Hi All,
> 
> I believe the IndVarSimplify is a bit too aggressive when it computes
> exit values. There are some cases where it is not beneficial to do so.
> For example, in the code below :
> 
> extern void func(unsigned val);
> 
> void test(unsigned m)
> {
>  unsigned a = 0;
> 
>  for (int i=0; i<186; i++) {
>    a += m;
>    func(a);
>  }
> 
>  func(a);
> }
> 
> Although the value of 'a' can be computed outside of the loop, there is
> no benefit in recomputing it : it is already computed and used in the
> loop in a way that can not be optimized away. When compiling the above
> testcase  with clang on x86, we get an unnecessary multiply.
> 
> Detecting (non) optimizable patterns is way to difficult, but we can
> still grasp some low hanging fruits if we can trivially determine there
> is no benefit.
> 
> Comments ?

Arnaud,

Your patch itself looks fine but I'm surprised by the approach. I expected the primary benefit of replacing exit values to be exposing constants outside the current loop to later acyclic optimization like sccp and instcombine. Those constants may be used inside different inner loops.

Why not always replace constant exit values?

Can we also look at the type of uses outside the loop. If they're all obviously nonoptimizable it's ok to skip exit value replacement (for non constants), otherwise we risk missing out on something. In this sort of situation I think it's also ok to just stop searching after 6 uses and just go ahead with the optimization.

I would at least gather optimization stats across llvm test-suite before supressing exit value replacement to make sure we're not preventing other optimization.

-Andy