[CIR][CIRGen][Builtin][Neon] Lower neon_vqadds_s32

[ghehg]

This can't be simply implemented by our CIR Add via LLVM::AddOp, as it's saturated add.

[bcardosolopes]

Looks like we have LLVM intrinsics for saturating instructions, have you considered changing binop to add a unitattr for saturation? Does the lowering for LLVM saturating intrinsics lead to the same neon instructions?

[bcardosolopes]

https://llvm.org/docs/LangRef.html#saturation-arithmetic-intrinsics

[ghehg]

Looks like we have LLVM intrinsics for saturating instructions, have you considered changing binop to add a unitattr for saturation? Does the lowering for LLVM saturating intrinsics lead to the same neon instructions?

I thought about it, wasn't sure if we're willing to saturation unitattr to BinOp as some kinds (like logical ones) wouldn't care about it.
But if you think it's worth it, certainly it is better approach in my opinion

[ghehg]

https://llvm.org/docs/LangRef.html#saturation-arithmetic-intrinsics

And LLVM dialect has that https://mlir.llvm.org/docs/Dialects/LLVM/#llvmintrsaddsat-llvmsaddsat

[ghehg]

Looks like we have LLVM intrinsics for saturating instructions, have you considered changing binop to add a unitattr for saturation? Does the lowering for LLVM saturating intrinsics lead to the same neon instructions?

Actually, thanks for the point. Surprisingly, LLVM saturating intrinsics does not lead to the neon instruction. It generates more cubersome instruction sequences.

[ghehg]

After talking to @bcardosolopes, implement this with CIR AddOp with saturated attribute. This attribute also applies to kind Sub too. Also in this PR, did some cleanup in BinOp LLVM Lowering as mentioned by @bcardosolopes comments as I understand it in
PR [CIR][Dialect] Add BinOpKind_Max.
So it makes sense to land this PR first, then rebase PR [CIR][Dialect] Add BinOpKind_Max later.

[bcardosolopes]

We can actually check for unsigned for mlir::IntegerType too, so perhaps it will be fine to just rely on adaptor type if we need to.