[clang] [flang] [flang] Add UNSIGNED (PR #113504)

[via cfe-commits]

================
@@ -968,21 +968,41 @@ struct BinaryOp {};
                                            fir::FirOpBuilder &builder,         \
                                            const Op &, hlfir::Entity lhs,      \
                                            hlfir::Entity rhs) {                \
-      return hlfir::EntityWithAttributes{                                      \
-          builder.create<GenBinFirOp>(loc, lhs, rhs)};                         \
+      if constexpr (Fortran::common::TypeCategory::GenBinTyCat ==              \
+                        Fortran::common::TypeCategory::Unsigned &&             \
+                    !std::is_same_v<GenBinFirOp, mlir::arith::DivUIOp>) {      \
+        int bits =                                                             \
+            Fortran::evaluate::Type<Fortran::common::TypeCategory::Integer,    \
+                                    KIND>::Scalar::bits;                       \
+        auto signlessType = mlir::IntegerType::get(                            \
+            builder.getContext(), bits,                                        \
+            mlir::IntegerType::SignednessSemantics::Signless);                 \
+        auto lhsSL = builder.createConvert(loc, signlessType, lhs);            \
----------------
jeanPerier wrote:

Thanks, I understand now, I mistook signless for meaning unsigned here (from an English semantic point of view, using "signless" and "unsigned" has two different things confuses me bit).

I had no idea MLIR arith operation rejected signed/unsigned integers. I am not seeing a strong rational for this other than the _"Existing call sites in tree are changed to use signless integer types now. Dialects can opt in to signed/unsigned integer types as following-up steps if that's desired."_  in [the thread](https://groups.google.com/a/tensorflow.org/g/mlir/c/XmkV8HOPWpo/m/7O4X0Nb_AQAJ) that introduced the signed integer concept in MLIR, and that nobody needed arith operations to accept those so nobody changed them.

Anyway, looks good then. There is a possibility that these casts will break pattern matching and canonicalization/optimization, but I am reluctant to go change this core arith dialect without concrete motivation.

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