Translate OpIAddCarry and OpISubBorrow back to llvm intrinsics

[vmaksimo]

Semantically we can translate OpIAddCarry and OpISubBorrow back into @llvm.uadd.with.overflow and @llvm.usub.with.overflow respectively. It require small transformation as there is a difference between return types in SPIR-V and LLVM IR - e.g., SPIR-V instructions return {i32, i32} struct, but LLVM intrinsics return {i32, i1}.

[VyacheslavLevytskyy]

CC: @maarquitos14

[maarquitos14]

Just a nit: LLVM guidelines require proper punctuation in comments (https://llvm.org/docs/CodingStandards.html#commenting).

[vmaksimo]

@maarquitos14 could you please point out where and what changes should be made? e.g. using suggestions in code review

[bwlodarcz]

@vmaksimo @VyacheslavLevytskyy @maarquitos14 What is the rationale behind this change? During forward translation from llvm.uadd/usub.with.overflow to OpIAddCarry/OpISubBorrow, we encounter a nearly pathological situation where conversion between types like {i32, i1} and {i32, i32} occurs. This conversion is costly for the user but is necessary for support (we need to accept valid intrinsics from frontends). The reverse translation appears to make the same costly trade-off and doesn't have the same requirement as forward.

@vmaksimo Overall PR LGTM.

[VyacheslavLevytskyy]

@llvm.uadd.with.overflow leads to insertion of __spirv_IAddCarry, and it's not something that run-time knows about. Any @llvm.uadd.with.overflow in the input now means a crash during run-time. This PR is to fix this by producing @llvm.uadd.with.overflow in the reverse translation.

[bwlodarcz]

@VyacheslavLevytskyy Could you clarify which runtime you're referring to? SPIR-V supports multiple runtimes (e.g., SYCL, OpenCL, Vulkan, etc.). If a change leads to a crash in one of the runtimes, it would indicate a bug within that specific runtime, rather than a reason to reduce usability for everyone else.

[VyacheslavLevytskyy]

The PR improves usability by producing a meaningful output of @llvm.uadd.with.overflow instead of a missing builtin __spirv_IAddCarry.

[bwlodarcz]

@VyacheslavLevytskyy If the backends did not adopt the built-in solution and it is non-standard, that is acceptable.

[svenvh]

LGTM, no objections.

[MrSidims]

As I've mentioned in offline discussion ideally we should separate built-in like translation from intrinsic-like translation under an option as in this case it might affect performances on GPU. This can be done separately.