[PATCH] D38494: [SCEV] Handling for ICmp occuring in the evolution chain.

Sanjoy Das via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 8 11:08:57 PST 2017


sanjoy added inline comments.


================
Comment at: lib/Analysis/ScalarEvolution.cpp:4095
+        BackedgeCond = BI->getCondition();
+        IsPositiveBackedgeCond = BI->getSuccessor(0) == L->getHeader();
+      }
----------------
jbhateja wrote:
> sanjoy wrote:
> > jbhateja wrote:
> > > sanjoy wrote:
> > > > jbhateja wrote:
> > > > > sanjoy wrote:
> > > > > > I think you also need to check that the false edge actually leaves the loop.  If both the edges out of the conditional branch branch to the header then this rewrite is not valid.
> > > > > > 
> > > > > > (Please also add a test case for the above situation ^).
> > > > > Can you give a scenario where this can happen ? A latch where both the branches have same desitination header ?  
> > > > Yes
> > > Yes ? @sanjoy, Can you provide a scenario/test in HLL where such situation is possible.  
> > I answered "yes" to your second question -- since that's precisely the situation I'm talking about:
> > 
> > ```
> > define void @foo(i1 %c) {
> > entry:
> >   br label %loop
> > 
> > loop:
> >   br i1 %c, label %loop, label %loop
> > }
> > ```
> > 
> Well, what I was checking was how can such an IR be generated ? Are we making any such check for both outgoing branches from a latch any where else in the code, because conditional branch instruction should become an unconditional branch in this scenario.
> 
> Shall revise this patch with your other comments, do add any thing else to save iteration ;-)  
> 
> instruction should become an unconditional branch in this scenario.

Correctness of transformations cannot rely on a specific optimization having happened -- you're right that in most cases the trivial conditional branch will be folded to an unconditional one, but we can't miscompile code if that optimization didn't happen for some reason or the other.


https://reviews.llvm.org/D38494





More information about the llvm-commits mailing list