[LLVMdev] induction variable computation not preserving scev

Dan Gohman gohman at apple.com
Thu Jan 20 11:23:47 PST 2011


On Jan 19, 2011, at 2:03 PM, Nick Lewycky wrote:

> On 19 January 2011 13:01, Dan Gohman <gohman at apple.com> wrote:
> 
> On Jan 18, 2011, at 12:32 AM, Nick Lewycky wrote:
> 
> > Hi,
> >
> > I tracked down a bug in indvars where we weren't updating SCEV properly. The attached patch shows the fix to this bug with a testcase, but it also causes five new test failures.
> 
> Indvars isn't restructuring the loop there, so it ideally shouldn't
> need to call forgetLoop().
> 
> Hmm? It certainly is, it's changing the condition on the branch instruction that makes up the loop latch!
> 
> Offhand, is it possible that the problem
> here is the same as the one in PR8037?
> 
> No, that only shows up when you try to run "opt -analyze -indvars -scalar-evolution" by causing a crash. With that patch in place, you can see that "opt -analyze -indvars -scalar-evolution" produces different values for the SCEVs than you get with "opt -indvars | opt -analyze -scalar-evolution" which led me to add the forgetLoop here.

Ah, I tried the testcase, saw the crash, and assumed that was the bug
you were aiming to fix. The forgetLoop() call shouldn't be necessary
for correctness. But I do see how ScalarEvolution's cached tripcounts
are sub-optimal in this case, because they retain the type of the loop's
original induction variable, rather than the type that indvars has
chosen for the new induction variable. So forgetLoop() makes sense
there.

Dan





More information about the llvm-dev mailing list