================
@@ -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:
Are these converts needed because some expression results may be typed with
"normal" MLIR integer type in lowering, like when lowering IAND and al. on
unsigned types?
That may be fine, I am asking to better understand the picture, and to try to
understand if some lowering code relying on the MLIR type to do some Fortran
level dispatch could act badly if there arguments are lowered like this (like
the REDUCE runtime calls that is using getTypeCode from FIRType.cpp to dispatch
from the mlir type of its arguments).
Do you some Fortran code that expose the need for this converts that I could
try to play with?
https://github.com/llvm/llvm-project/pull/113504
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
