[SPIR-V] Allow intrinsics with aggregate return type to reach GlobalISel

[VyacheslavLevytskyy]

Two main goals of this PR are:

• to support "Arithmetic with Overflow" intrinsics, including the special case when those intrinsics are being generated by the CodeGenPrepare pass during translations with optimization;
• to redirect intrinsics with aggregate return type to be lowered via GlobalISel operations instead of SPIRV-specific unfolding/lowering (see [SPIR-V] Lower llvm.x.with.overflow intrinsics #95012).

There is a new test case llvm/test/CodeGen/SPIRV/passes/translate-aggregate-uaddo.ll that describes and checks the general logics of the translation.

This PR continues a series of PRs aimed to identify and fix flaws in code emission, to improve pass rates for the mode with expensive checks set on (see #101732, #104104, #106966), having in mind the ultimate goal of proceeding towards the non-experimental status of SPIR-V Backend.

The reproducers are:

1. consider llc -O3 -mtriple=spirv64-unknown-unknown ... with:

define spir_func i32 @foo(i32 %a, ptr addrspace(4) %p) {
entry:
  br label %l1

l1:
  %e = phi i32 [ %a, %entry ], [ %i, %body ]
  %i = add nsw i32 %e, 1
  %fl = icmp eq i32 %i, 0
  br i1 %fl, label %exit, label %body

body:
  store i8 42, ptr addrspace(4) %p
  br label %l1

exit:
  ret i32 %i
}

2. consider llc -O0 -mtriple=spirv64-unknown-unknown ... with:

define spir_func i32 @foo(i32 %a, ptr addrspace(4) %p) {
entry:
  br label %l1

l1:                                               ; preds = %body, %entry
  %e = phi i32 [ %a, %entry ], [ %math, %body ]
  %0 = call { i32, i1 } @llvm.uadd.with.overflow.i32(i32 %e, i32 1)
  %math = extractvalue { i32, i1 } %0, 0
  %ov = extractvalue { i32, i1 } %0, 1
  br i1 %ov, label %exit, label %body

body:                                             ; preds = %l1
  store i8 42, ptr addrspace(4) %p, align 1
  br label %l1

exit:                                             ; preds = %l1
  ret i32 %math
}

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[VyacheslavLevytskyy]

FYI @efriedma-quic

[s-perron]

Looks okay with my limited knowledge, but I did not understand one part.

[Keenuts]

This is supposed to be the list of internal intrinsics not returning void?

[VyacheslavLevytskyy]

Almost, but not exactly. This list doesn't include int_spv_gep, for example, because it returns ptr type. This list is to include internal intrinsics that returns a non-ptr value and so may potentially (but should not actually) participate in fake_use emission.

[Keenuts]

In that case, isn't the return type fetchable from the CallBase parent class? Or am I missing something? (Seems like maintaining a list like that is bound to end up wrong)

[VyacheslavLevytskyy]

I think you are right. My motivation was to explore the topic further and widen applicability of this PR's way to pass info through passes, but we may extend/address this later if needed. Another motivation was that internal intrinsics are intended for quite different things, and it's hard to separate them as a class to use in conditions, but this again doesn't matter in case of this PR specifically.

So for goals of this PR it may be better indeed to be more general and don't list intrinsics explicitly, and I've changed the explicit list to F->getName().starts_with("llvm.spv.") to exclude internal SPIR-V backend intrinsics.