[llvm] [LoopVectorize] Don't assert in getVectorCallCost for vector library variants (PR #202085)

[Florian Hahn via llvm-commits]

================
@@ -0,0 +1,114 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py UTC_ARGS: --version 6
+; RUN: opt < %s -passes=loop-vectorize -force-vector-interleave=1 -force-vector-width=2 -S 2>&1 | FileCheck %s
+
+; Regression test for the cost model. A conditionally-executed call has a vector
+; library variant matching the VF, so the call itself is a widen-with-mask
+; candidate (not scalar-with-predication). Its result feeds a scatter store that
+; *is* scalar-with-predication. While computing the predication discount for that
+; store, computePredInstDiscount walks the operand chain and queries the cost of
+; the call at the vector VF via getVectorCallCost. This used to hit an assert
+; ("getVectorCallCost does not price vector library variants"); the variant is
+; now priced via TTI.getCallInstrCost instead of crashing.
----------------
fhahn wrote:

would be good to keep the comment a bit more generic, saying that it checks that we correctly handle wide calls when checking if scalarization is profitable or something like that, to avoid referring to specific functions in the implementation

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