[llvm] [llvm][ipsccp/sccp] Strengthen range analysis in SCCPSolver (PR #111716)

[Nikita Popov via llvm-commits]

================
@@ -0,0 +1,43 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py UTC_ARGS: --version 5
+; RUN: opt < %s -passes=ipsccp -S | FileCheck %s
+
+define i32 @foo() {
+; CHECK-LABEL: @foo(
+; CHECK-NEXT:  init:
+; CHECK-NEXT:    br label %[[OUTER_LOOP_CONTROL:.*]]
+; CHECK:       outer.loop.control:
+; CHECK-NEXT:    [[X_0:%.*]] = phi i32 [ 0, [[INIT:%.*]] ], [ [[X_OUTER:%.*]], [[OUTER_LOOP_INC:%.*]] ]
+; CHECK-NEXT:    [[TMP0:%.*]] = icmp slt i32 [[X_0]], 10
+; CHECK-NEXT:    br i1 [[TMP0]], label %[[INNER_LOOP_CONTROL:.*]], label %[[EXIT:.*]]
+; CHECK:       inner.loop.control:
+; CHECK-NEXT:    br label [[OUTER_LOOP_INC]]
+; CHECK:       outer.loop.inc:
+; CHECK-NEXT:    [[X_OUTER]] = add nsw i32 [[X_0]], 2
+; CHECK-NEXT:    br label %[[OUTER_LOOP_CONTROL]]
+; CHECK:       exit:
+; CHECK-NEXT:    ret i32 [[X_0]]
+;
+init:
+  br label %outer.loop.control
+
+outer.loop.control:                                                ; preds = %init, %outer.loop.inc
+  %x.0 = phi i32 [ 0, %init ], [ %x.outer, %outer.loop.inc ]
+  %0 = icmp slt i32 %x.0, 10
+  br i1 %0, label %inner.loop.control, label %exit
+
+inner.loop.control:                                                ; preds = %outer.loop.control, %inner.loop.body
+  %x.1 = phi i32 [ %x.0, %outer.loop.control ], [ %x.inner, %inner.loop.body ]
+  %1 = icmp sgt i32 %x.1, 20
----------------
nikic wrote:

Regarding https://github.com/llvm/llvm-project/issues/108906, I agree that we should not try to optimize such cases. If I ever find the time, I'll write a new section for the developer policy that specifies requirements for fuzzer-generated issue.

As for the change itself, I think the idea behind it is fairly reasonable, and I expect that it will help more realistic cases as well. Unfortunately, we're currently pretty bad with bounds checks elimination in loops for a combination of different reasons (SCEV being glacially slow with context sensitive facts, LVI going to overdefined in cycles, ConstraintElimination only having very basic loop reasoning, etc).

I see some code size changes from this patch: http://llvm-compile-time-tracker.com/compare.php?from=eaea5f6f952b6059cebfe87ea9800a3a6516f9ed&to=6358352b3b4a9912e4dd312fad057b02833a7faa&stat=size-text And also significant compile-time regressions, so we'll have to see if we can make it cheap enough: http://llvm-compile-time-tracker.com/compare.php?from=eaea5f6f952b6059cebfe87ea9800a3a6516f9ed&to=6358352b3b4a9912e4dd312fad057b02833a7faa&stat=instructions%3Au I haven't had time to look at the implementation yet.

https://github.com/llvm/llvm-project/pull/111716