[PATCH] D17174: [LVI] Greatly strengthen inductive reasoning on predicates

Sanjoy Das via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 22 18:03:02 PST 2016


sanjoy added a comment.

I think (but am by no means sure) that this change can pessimize some cases.  Since LVI does not have `-analyze`, that is somewhat difficult to demonstrate, but if you have

  define i8 @g(i32 %a, i32 %length, i1* %cc) {
  entry:
    br label %loop
  
  loop:
    %iv = phi i32 [0, %entry], [%iv.next, %backedge]
    %iv.next = add i32 %iv, 1
    %cnd = icmp sgt i32 %iv.next, 0
    br i1 %cnd, label %backedge, label %exit
  
  backedge:
    %cont = icmp slt i32 %iv.next, 400
    br i1 %cont, label %loop, label %exit
  
  exit:
    ret i8 0
  }

Then on master, running `opt -S -jump-threading -debug-only=lazy-value-info -disable-output < FileName` (crude replacement for `-analyze -lazy-value-info`) gives me:

  LVI Getting value   %iv.next = add i32 %iv, 1 at ''
    Result = overdefined
  LVI Getting value   %iv.next = add i32 %iv, 1 at ''
    Result = overdefined
  LVI Getting edge value   %iv.next = add i32 %iv, 1 from 'loop' to 'backedge'
  PUSH:   %iv.next = add i32 %iv, 1 in loop
  PUSH:   %iv = phi i32 [ 0, %entry ], [ %iv.next, %backedge ] in loop
  PUSH:   %iv.next = add i32 %iv, 1 in backedge
  POP   %iv.next = add i32 %iv, 1 in backedge = constantrange<1, -2147483648>
  POP   %iv = phi i32 [ 0, %entry ], [ %iv.next, %backedge ] in loop = constantrange<0, 400>
  POP   %iv.next = add i32 %iv, 1 in loop = constantrange<1, 401>
    Result = constantrange<1, 401>
  LVI Getting edge value   %iv.next = add i32 %iv, 1 from 'loop' to 'backedge'
    Result = constantrange<1, 401>

but after your change I get

  LVI Getting value   %iv.next = add i32 %iv, 1 at ''
  LVI Getting block end value   %iv.next = add i32 %iv, 1 at 'loop'
  PUSH:   %iv = phi i32 [ 0, %entry ], [ %iv.next, %backedge ] in loop
  PUSH:   %iv.next = add i32 %iv, 1 in backedge
  PUSH:   %iv.next = add i32 %iv, 1 in loop
  POP   %iv.next = add i32 %iv, 1 in loop = overdefined
  POP   %iv.next = add i32 %iv, 1 in backedge = constantrange<1, -2147483648>
  POP   %iv = phi i32 [ 0, %entry ], [ %iv.next, %backedge ] in loop = constantrange<0, 400>
    reuse BB 'loop' val=overdefined
    Result = overdefined
    Result = overdefined
  LVI Getting value   %iv.next = add i32 %iv, 1 at ''
  LVI Getting block end value   %iv.next = add i32 %iv, 1 at 'backedge'
    Result = constantrange<1, -2147483648>
    Result = constantrange<1, -2147483648>
  LVI Getting edge value   %iv.next = add i32 %iv, 1 from 'loop' to 'backedge'
    Result = constantrange<1, -2147483648>
  LVI Getting edge value   %iv.next = add i32 %iv, 1 from 'loop' to 'backedge'
    Result = constantrange<1, -2147483648>

The difference is in `LVI Getting edge value   %iv.next = add i32 %iv, 1 from 'loop' to 'backedge'`.  **However** I am yet to make this "regression" result in a missed transform; so it is very possible that there is an invariant on why the above difference does not matter by construction.  Is that the case?

I think you had explained this to me in person before, but putting this in writing will both help me remember what we decided, and is also good for record.


================
Comment at: lib/Analysis/LazyValueInfo.cpp:1159
@@ +1158,3 @@
+
+  if (!hasBlockValue(V, BB))
+    // To detect cyles, we only ever push any particular item on the stack at
----------------
Minor stylistic thing:  I'd keep the braces around the body, even if they're not syntactically required.  The body is fairly big, textually.


http://reviews.llvm.org/D17174





More information about the llvm-commits mailing list