[llvm] [VPlan] Add VPValue for VF, use it for VPWidenIntOrFpInductionRecipe. (PR #95305)

[David Sherwood via llvm-commits]

================
@@ -385,8 +381,8 @@ define void @test_reversed_load2_store2(ptr noalias nocapture readonly %A, ptr n
 ; CHECK-NEXT:    [[TMP1:%.*]] = shl nuw nsw i64 [[TMP0]], 2
 ; CHECK-NEXT:    [[TMP2:%.*]] = call <vscale x 4 x i32> @llvm.experimental.stepvector.nxv4i32()
 ; CHECK-NEXT:    [[INDUCTION:%.*]] = sub <vscale x 4 x i32> shufflevector (<vscale x 4 x i32> insertelement (<vscale x 4 x i32> poison, i32 1023, i64 0), <vscale x 4 x i32> poison, <vscale x 4 x i32> zeroinitializer), [[TMP2]]
-; CHECK-NEXT:    [[TMP3:%.*]] = call i32 @llvm.vscale.i32()
-; CHECK-NEXT:    [[DOTNEG:%.*]] = mul nsw i32 [[TMP3]], -4
+; CHECK-NEXT:    [[TMP3:%.*]] = trunc nuw nsw i64 [[TMP1]] to i32
----------------
david-arm wrote:

I think what you say makes sense. It's just I wasn't sure if the VF*UF not wrapping assumption was in the unsigned or signed sense. I don't think I explained it well in my original comment though to be fair. :) Another example is 0x3FFFFFFF * 4, which would wrap in a signed sense and imply poison in the original code. To be honest, I'm not sure what 'trunc nuw nsw' actually means in practice, for example what does it mean to truncate (i64 0xFFFFFFFC) -> (i32 0xFFFFFFFC)? You could argue that a positive value as a i64 has now wrapped to become a negative i32 value, so probably I don't understand how nsw for trunc works!

Anyway, I'm happy with your explanation, but perhaps it would be good to spell out in a comment somewhere (not necessarily this patch) that VF * UF is not expected to wrap in either a unsigned or signed sense.

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