[llvm] [LV] Avoid collapsing VF to zero when a loop has no memory ops or reductions (PR #216266)

[Florian Hahn via llvm-commits]

================
@@ -0,0 +1,53 @@
+; NOTE: Assertions have been autogenerated by utils/update_analyze_test_checks.py UTC_ARGS: --filter "The Smallest and Widest types" --filter "Selecting VF" --filter "Vectorization is possible but not beneficial" --version 6
+; REQUIRES: asserts
+; RUN: opt -passes=loop-vectorize -mtriple riscv64 -mattr=+v \
+; RUN:   -debug-only=loop-vectorize -disable-output -S < %s 2>&1 | \
+; RUN:   FileCheck %s --check-prefix=DEFAULT
+; RUN: opt -passes=loop-vectorize -mtriple riscv64 -mattr=+v \
+; RUN:   -vectorizer-maximize-bandwidth \
+; RUN:   -debug-only=loop-vectorize -disable-output -S < %s 2>&1 | \
+; RUN:   FileCheck %s --check-prefix=MAXBW
+
+; This is an early-exit search loop with no loads/stores and no reductions, so
+; getSmallestAndWidestTypes() cannot observe any element type. The smallest type
+; is reported as equal to the widest type instead of the -1U sentinel, so the
+; max-bandwidth VF computation does not divide the register width by the
+; sentinel and collapse the VF to zero. With and without
+; -vectorizer-maximize-bandwidth we pick the same VF.
+
+define i32 @find_first_ge(i32 %n, i32 %target) {
+; DEFAULT-LABEL: 'find_first_ge'
+; DEFAULT:  LV: The Smallest and Widest types: 8 / 8 bits.
+; DEFAULT:  LV: Selecting VF: vscale x 16.
+;
+; MAXBW-LABEL: 'find_first_ge'
+; MAXBW:  LV: The Smallest and Widest types: 8 / 8 bits.
+; MAXBW:  LV: Selecting VF: vscale x 16.
+;
+entry:
+  %cmp.not = icmp eq i32 %n, 0
----------------
fhahn wrote:

this should not be needed?

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