================
@@ -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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
