[llvm-commits] ScalarEvolution fix for treeadd

[Dan Gohman]

> > Would it be too intrusive to ask ScalarEvolution to use a
> > PostDominanceFrontier for this?
> 
> No, that's what I implemented at first. Unfortunately, it doesn't cover
> all the possible cases (specifically, it broke 2007-01-06-TripCount.ll).
> 
> In 2007-01-06-TripCount.ll there's two "loops" sharing one loop header.
> The first runs from header -> exit -> A -> header and the other is
> header -> B -> A -> header. I was testing exit postdom header, which it
> does, but that didn't catch this case where the transform is still
> unsafe.
> 
> If you think I merely had my test wrong, please let me know what you
> think it ought to be and I'll implement it and see.

I do think you merely had the wrong test. The post-dominance frontiers
are needed here.

Running -analyze -postdomfrontier on 2007-01-06-TripCount.ll gives this:

Printing analysis 'Post-Dominance Frontier Construction' for function 'test':
  DomFrontier for BB %bb is:     %bb2 %cond_next
  DomFrontier for BB %bb2 is:    %bb2 %cond_next
  DomFrontier for BB %cond_true is:      %bb2
  DomFrontier for BB %cond_next is:      %cond_next
  DomFrontier for BB %bb6 is:
  DomFrontier for BB %return is:
  DomFrontier for BB %entry is:

It looks like %bb2 is the loop header, and %cond_next is the block that
contains the exit branch. The frontier sets for these two blocks are
different, so they're not control-equivalent, and that disqualifies the
loop for what ScalarEvolution is doing here.

Dan

-- 
Dan Gohman, Cray Inc.