LLVM: field addition with saturated fields

[mratsim]

This PR merges several experiments to implement modular addition in pure LLVM IR so that instead of writing an assembly backend for each target we can generate multiplatform code from LLVM IR, especially for ARM and AMDGPU as they support addition-with-carry and also SIMD, without doing vectorization myself.

That was to try to address:

• GPU backends #92
• SIMD Vectorization - Use Integer Fused Multiply-Add (AVX512) #427
• Perf: Assembly code generator for ARM and ARM64 #200

Unfortunately, compilers are still inefficient at translating modular addition into optimal code.
See #357:

• [Aarch64] Missed optimization: substraction with borrow llvm/llvm-project#102062
• [x86 / Clang] Pessimization: missed fusion of substraction/compare/cmov after -O1 optimization or extra caller. llvm/llvm-project#102868
• [Isel x86/Aarch64] i320+ generates useless 33% extra instructions when chaining sub.with.overflow and select / conditional moves. llvm/llvm-project#103717

Description of experiments:

• 432a91e implements word-level (so 64-bit by 64-bit) modular addition with inlined adc/sbb "super-instructions" (and mulExt/muladd1/muladd2/mulacc). This generates optimal code on x86-64 but not on ARM due to [Aarch64] Missed optimization: substraction with borrow llvm/llvm-project#102062, and the alloca needs to be specialized to addrspace(5) on AMDGPUs: [AMDGPU] llc crash in 'AMDGPU DAG->DAG Pattern Instruction Selection' llvm/llvm-project#102058
• 0354d5b refactors the IR to add callable functions, linkage, calling conventions and boilerplate reductions
• 08b8671 introduces inline/alwaysinline functions failing to work around the bad codegen. Unfortunately inlining breaks instruction sub/icmp fusion into a single sub-with-borrow
• a76cfd8 partially works around inlining and instruction fusion by not using an inlining pass, only alwaysinline
• b415418 materializes addcarry/subborrow as actual functions in LLVM IR instead of being just a sequence of instructions. Unfortunately it doesn't optimize well on ARM [Aarch64] Missed optimization: substraction with borrow llvm/llvm-project#102062
• 480ede5 uses builtin llvm.uadd.with.overflow llvm.usub.with.overflow to try to workaround bad codegen. While it is portable to x86 and ARM for up to 256-bit primes, there are 33% extra instructions for prime fields beyond that threshold [Isel x86/Aarch64] i320+ generates useless 33% extra instructions when chaining sub.with.overflow and select / conditional moves. llvm/llvm-project#103717