[PATCH] D63885: [LOOPINFO] Introduce the loop guard API.

[Philip Reames via Phabricator via llvm-commits]

reames added inline comments.


================
Comment at: llvm/include/llvm/Analysis/LoopInfo.h:737
+  /// dominates the loop header, and the other successor postdominates the loop
+  /// header, i.e. the branch instruction \p BI is a loop guard.
+  bool isLoopGuardBranch(const BranchInst &BI, const DominatorTree &DT,
----------------
Whitney wrote:
> reames wrote:
> > Whitney wrote:
> > > reames wrote:
> > > > Your definition would seem to disallow:
> > > > if (C) return;
> > > > for (...) {}
> > > > 
> > > > That is C wouldn't be considered a guard condition.  Intentional?  
> > > I think this is fine, in most cases, LLVM tries to common the return blocks, so `if (C)` will jump to the common exit block, and this algorithm will work. Although we can intensionally write LLVMIR with multiple return blocks, I don't think it will be the common case. 
> > Put two calls on the return paths to different targets and we don't merge them.
> Do you mind giving me an example? I tried the code below, and that doesn't work. 
> ```
> void bar1();
> void bar2();
> int foo(bool cond, int *A) {
>   if (cond) return 1;
>   for (long i = 0; i < 100; ++i) {
>     A[i] = 0;
>   }
>   bar1();
>   bar2();
>   return 0;
> }
> ```
void bar1();
void bar2();
int foo(bool cond, int *A) {
  if (cond) { bar1(); return 1; }
  for (long i = 0; i < 100; ++i) {
    A[i] = 0;
  }
  bar2();
  return 0;
}


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63885/new/

https://reviews.llvm.org/D63885