Unhandled Floating point exception with loop-vectorize

[TatyanaDoubts]

Run opt with -passes=loop-vectorize

https://godbolt.org/z/s3PWY3vhE

Test.ll

; ModuleID = './reduced.ll'
source_filename = "./reduced.ll"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128-ni:1-p2:32:8:8:32-ni:2"
target triple = "x86_64-unknown-linux-gnu"

define ptr addrspace(1) @wombat(i64 %arg, ptr addrspace(1) %arg1) gc "statepoint-example" {
bb:
  br label %bb2

bb2:                                              ; preds = %bb4, %bb
  br label %bb3

bb3:                                              ; preds = %bb3, %bb2
  %phi = phi i64 [ 0, %bb2 ], [ %add, %bb3 ]
  %add = add i64 %phi, 1
  %load = load i8, ptr addrspace(1) %arg1, align 1
  %shl = shl i64 0, 0
  store i16 0, ptr addrspace(1) null, align 2
  %icmp = icmp ult i64 %phi, %arg
  br i1 %icmp, label %bb3, label %bb4

bb4:                                              ; preds = %bb3
  br i1 false, label %bb5, label %bb2, !prof !0

bb5:                                              ; preds = %bb4
  ret ptr addrspace(1) null
}

!0 = !{!"branch_weights", i32 1, i32 -1}

[DaniilSuchkov]

It started failing after 962fbaf

Author: David Sherwood <57997763+david-arm@users.noreply.github.com>
Date:   Fri Jan 26 14:43:48 2024 +0000

    [LoopVectorize] Refine runtime memory check costs when there is an outer loop (#76034)

    When we generate runtime memory checks for an inner loop it's
    possible that these checks are invariant in the outer loop and
    so will get hoisted out. In such cases, the effective cost of
    the checks should reduce to reflect the outer loop trip count.

    This fixes a 25% performance regression introduced by commit

    49b0e6dcc296792b577ae8f0f674e61a0929b99d

    when building the SPEC2017 x264 benchmark with PGO, where we
    decided the inner loop trip count wasn't high enough to warrant
    the (incorrect) high cost of the runtime checks. Also, when
    runtime memory checks consist entirely of diff checks these are
    likely to be outer loop invariant.

We have a division by 0 here 962fbaf#diff-da321d454a7246f8ae276bf1db2782bf26b5210b8133cb59e4d7fd45d0905decR2114 because getLoopEstimatedTripCount(OuterLoop) just above that line returns 0.

[david-arm]

OK thanks for raising this issue - I'll take a look this morning!

[david-arm]

I have a fix in review - #81721