[clang] [mlir] [MLIR][OpenMP] Add OpenMP_IntLikeTypeInterface to allow other dialect inputs to omp ops (PR #196363)
https://github.com/jsjodin updated
https://github.com/llvm/llvm-project/pull/196363
>From d89188caa7dc550f68e5dfe0fc639deb11895e34 Mon Sep 17 00:00:00 2001
From: Jan Leyonberg
Date: Thu, 7 May 2026 11:46:37 -0400
Subject: [PATCH] [MLIR][OpenMP] Add IntLkeType to allow other dialect inputs
to omp ops
This patch adds an IntLikeType interface to allow e.g. CIR ops to be inputs to
OpenMP dialect operations.
---
.../OpenMP/RegisterOpenMPExtensions.cpp | 9 +++
.../mlir/Dialect/OpenMP/OpenMPOpBase.td | 5 ++--
mlir/include/mlir/IR/BuiltinTypeInterfaces.td | 25 +++
mlir/include/mlir/IR/BuiltinTypes.td | 1 +
mlir/test/Dialect/OpenMP/invalid.mlir | 2 +-
5 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/clang/lib/CIR/Dialect/OpenMP/RegisterOpenMPExtensions.cpp
b/clang/lib/CIR/Dialect/OpenMP/RegisterOpenMPExtensions.cpp
index 3a66f93238808..eb4c5efe7c86a 100644
--- a/clang/lib/CIR/Dialect/OpenMP/RegisterOpenMPExtensions.cpp
+++ b/clang/lib/CIR/Dialect/OpenMP/RegisterOpenMPExtensions.cpp
@@ -13,6 +13,7 @@
#include "clang/CIR/Dialect/OpenMP/RegisterOpenMPExtensions.h"
#include "mlir/Dialect/OpenMP/OpenMPDialect.h"
#include "mlir/Dialect/OpenMP/OpenMPInterfaces.h"
+#include "mlir/IR/BuiltinTypes.h"
#include "clang/CIR/Dialect/IR/CIRDialect.h"
#include "clang/CIR/Dialect/IR/CIRTypes.h"
@@ -24,6 +25,13 @@ struct OpenMPPointerLikeModel
return mlir::cast(pointer).getPointee();
}
};
+
+struct CIRIntLikeModel
+: public mlir::IntLikeType::ExternalModel {
+ unsigned getWidth(mlir::Type type) const {
+return mlir::cast(type).getWidth();
+ }
+};
} // namespace
namespace cir::omp {
@@ -33,6 +41,7 @@ void registerOpenMPExtensions(mlir::DialectRegistry
®istry) {
cir::FuncOp::attachInterface<
mlir::omp::DeclareTargetDefaultModel>(*ctx);
cir::PointerType::attachInterface(*ctx);
+cir::IntType::attachInterface(*ctx);
});
}
diff --git a/mlir/include/mlir/Dialect/OpenMP/OpenMPOpBase.td
b/mlir/include/mlir/Dialect/OpenMP/OpenMPOpBase.td
index c1017826ab0c9..7fba05ff32375 100644
--- a/mlir/include/mlir/Dialect/OpenMP/OpenMPOpBase.td
+++ b/mlir/include/mlir/Dialect/OpenMP/OpenMPOpBase.td
@@ -17,6 +17,7 @@ include "mlir/Dialect/OpenMP/OpenMPAttrDefs.td"
include "mlir/Dialect/OpenMP/OpenMPDialect.td"
include "mlir/Dialect/OpenMP/OpenMPOpsInterfaces.td"
include "mlir/Dialect/OpenMP/OpenMPTypeInterfaces.td"
+include "mlir/IR/BuiltinTypeInterfaces.td"
include "mlir/IR/OpBase.td"
//===--===//
@@ -28,8 +29,8 @@ class OpenMP_Type :
let mnemonic = typeMnemonic;
}
-// Type which can be constraint accepting standard integers and indices.
-def IntLikeType : AnyTypeOf<[AnyInteger, Index]>;
+def IntLikeType : AnyTypeOf<[AnyInteger, Index,
+TypeAlias]>;
def OpenMP_PointerLikeType : TypeAlias;
diff --git a/mlir/include/mlir/IR/BuiltinTypeInterfaces.td
b/mlir/include/mlir/IR/BuiltinTypeInterfaces.td
index 93c8c0694b467..a60ab88baf387 100644
--- a/mlir/include/mlir/IR/BuiltinTypeInterfaces.td
+++ b/mlir/include/mlir/IR/BuiltinTypeInterfaces.td
@@ -158,6 +158,31 @@ def FloatTypeInterface : TypeInterface<"FloatType",
}];
}
+//===--===//
+// IntLikeTypeInterface
+//===--===//
+
+def IntLikeTypeInterface : TypeInterface<"IntLikeType"> {
+ let cppNamespace = "::mlir";
+ let description = [{
+This type interface should be implemented by integer-like types. It
provides
+a common API for querying the bit width of the integer type. This is useful
+for dialects that need to accept integer-like types from other dialects,
+e.g. for loop bounds, steps, and other integer operands.
+ }];
+
+ let methods = [
+InterfaceMethod<
+ /*desc=*/[{
+Returns the bit width of this integer-like type.
+ }],
+ /*retTy=*/"unsigned",
+ /*methodName=*/"getWidth",
+ /*args=*/(ins)
+>
+ ];
+}
+
//===--===//
// MemRefElementTypeInterface
//===--===//
diff --git a/mlir/include/mlir/IR/BuiltinTypes.td
b/mlir/include/mlir/IR/BuiltinTypes.td
index 20c41c5f79729..9e9c064419fc6 100644
--- a/mlir/include/mlir/IR/BuiltinTypes.td
+++ b/mlir/include/mlir/IR/BuiltinTypes.td
@@ -597,6 +597,7 @@ def Builtin_Index : Builtin_Type<"Index", "index",
def Builtin_Integer : Builtin_Type<"Integer", "integer",
[VectorElementTypeInterface, QuantStorageTypeInterface,
+ IntLikeTypeInterface,
DeclareTypeInterfaceMethods]> {
diff --git a/mlir/test/Dialect/OpenMP/invalid.mlir
b/mlir/test/Dialect/OpenMP/invalid.mlir
index 71b46a4baa0bc..feee4cc2affa3 100644
--- a/mlir/test/Dialect/OpenMP/invalid.mlir
+++ b/mlir/test/Dialect/OpenMP/invalid.
[clang] [mlir] [MLIR][OpenMP] Add OpenMP_IntLikeTypeInterface to allow other dialect inputs to omp ops (PR #196363)
xlauko wrote: > > I would think of `UnrealizedConversionCastOps` surviving multiple steps not > > really idomatic, they are meant to just note "here is some conversion that > > needs to be hadeled later in this pass", ideally in between passes you > > sould have IR that has some expected form. > > On the other hand why `OpenMP_IntLikeTypeInterface` and not introducing > > this to core mlir similarly to floats and pointers? Then arbitrary consumer > > of CIR can use the interface not just OpenMP. > > Also present solution would require attaching `OpenMP_IntLikeTypeInterface` > > to CIR types which creates not nice dependency direction in my opinion. > > Do you mean there should be Pointer/Int/Float-like interfaces in core MLIR > that both OMP and CIR could refer to? It seems like a doable solution > depending on how difficult it would be to agree in what should be in those > interfaces. In the OMP-specific interfaces we can choose what is relevant for > those types and makes it clear what CIR needs to provide to be an input to > OMP operations. IMO the dependency on CIR->OMP isn't too bad in the sense > that CIR is the base language and essentially imports OMP. We have a > precedent with flang/FIR already, although that particular point may not be a > good argument if that is a poor design choice. Yes, I just realised, OMP uses custom ones also for pointers and floats. I thought it is using core MLIR's `PtrLikeTypeInterface` and `FloatTypeInterface` see (https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/IR/BuiltinTypeInterfaces.td). Only IntegerTypeInterface is missing there. I would suggest making an RFC for this addition. What I don't like about CIR->OMP dependency is that it will converge to similar pattern for other consumers, and suddenly you have OpenMP_IntLikeTypeInterface, OpenACC_IntLikeTypeInterface, MyCustom_IntLikeTypeInterface all representing the same fact. https://github.com/llvm/llvm-project/pull/196363 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [mlir] [MLIR][OpenMP] Add OpenMP_IntLikeTypeInterface to allow other dialect inputs to omp ops (PR #196363)
jsjodin wrote: > I would think of `UnrealizedConversionCastOps` surviving multiple steps not > really idomatic, they are meant to just note "here is some conversion that > needs to be hadeled later in this pass", ideally in between passes you sould > have IR that has some expected form. > > On the other hand why `OpenMP_IntLikeTypeInterface` and not introducing this > to core mlir similarly to floats and pointers? Then arbitrary consumer of CIR > can use the interface not just OpenMP. > > Also present solution would require attaching `OpenMP_IntLikeTypeInterface` > to CIR types which creates not nice dependency direction in my opinion. Do you mean there should be Pointer/Int/Float-like interfaces in core MLIR that both OMP and CIR could refer to? It seems like a doable solution depending on how difficult it would be to agree in what should be in those interfaces. In the OMP-specific interfaces we can choose what is relevant for those types and makes it clear what CIR needs to provide to be an input to OMP operations. IMO the dependency on CIR->OMP isn't too bad in the sense that CIR is the base language and essentially imports OMP. We have a precedent with flang/FIR already, although that particular point may not be a good argument if that is a poor design choice. https://github.com/llvm/llvm-project/pull/196363 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [mlir] [MLIR][OpenMP] Add OpenMP_IntLikeTypeInterface to allow other dialect inputs to omp ops (PR #196363)
xlauko wrote: I would think of `UnrealizedConversionCastOps` surviving multiple steps not really idomatic, they are meant to just note "here is some conversion that needs to be hadeled in this pass", ideally in between passes you sould have IR that has some expected form. On the other hand why `OpenMP_IntLikeTypeInterface` and not introducing this to core mlir similarly to floats and pointers? Then arbitrary consumer of CIR can use the interface not just OpenMP. Also present solution would require attaching `OpenMP_IntLikeTypeInterface` to CIR types which creates not nice dependency direction in my opinion. https://github.com/llvm/llvm-project/pull/196363 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [mlir] [MLIR][OpenMP] Add OpenMP_IntLikeTypeInterface to allow other dialect inputs to omp ops (PR #196363)
https://github.com/jsjodin edited https://github.com/llvm/llvm-project/pull/196363 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [mlir] [MLIR][OpenMP] Add OpenMP_IntLikeTypeInterface to allow other dialect inputs to omp ops (PR #196363)
https://github.com/tblah commented: Why did you decide to opt for a new interface instead of just converting the CIR integers into mlir intrinsic integer types? I'm worried that with this verifier change, you could have valid OpenMP dialect code using types which are not supported by the translation to LLVM-IR https://github.com/llvm/llvm-project/pull/196363 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [mlir] [MLIR][OpenMP] Add OpenMP_IntLikeTypeInterface to allow other dialect inputs to omp ops (PR #196363)
jsjodin wrote: > `UnrealizedConversionCastOp` Maybe I'm misunderstanding the use of the UnrealizedConversionCastOp. It seemed like these UnrealizedConversionCastOps cast ops would survive for some time in the compilation flow and not just during a translation to handle type conflicts temporarily. I guess the question is that if we want to write analyses and optimizations at the CIR-OMP level, would these casts be present? https://github.com/llvm/llvm-project/pull/196363 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [mlir] [MLIR][OpenMP] Add OpenMP_IntLikeTypeInterface to allow other dialect inputs to omp ops (PR #196363)
andykaylor wrote: > > Why did you decide to opt for a new interface instead of just converting > > the CIR integers into mlir intrinsic integer types? > > I'm worried that with this verifier change, you could have valid OpenMP > > dialect code using types which are not supported by the translation to > > LLVM-IR > > When constructing CIR/OMP the types used are defined in CIR which we cannot > avoid when constructing the OMP operations since everything is happening at > once in the front-end. They do get lowered to the LLVM IR dialect before the > OMP operations are lowered to LLVM-IR, so there should be no issues regarding > unsupported types. For OpenACC @erichkeane handled this by creating an `UnrealizedConversionCastOp` to be handled during lowering or some other dialect transform. https://github.com/llvm/llvm-project/pull/196363 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [mlir] [MLIR][OpenMP] Add OpenMP_IntLikeTypeInterface to allow other dialect inputs to omp ops (PR #196363)
jsjodin wrote: > Why did you decide to opt for a new interface instead of just converting the > CIR integers into mlir intrinsic integer types? > > I'm worried that with this verifier change, you could have valid OpenMP > dialect code using types which are not supported by the translation to LLVM-IR When constructing CIR/OMP the types used are defined in CIR which we cannot avoid when constructing the OMP operations since everything is happening at once in the front-end. They do get lowered to the LLVM IR dialect before the OMP operations are lowered to LLVM-IR, so there should be no issues regarding unsupported types. https://github.com/llvm/llvm-project/pull/196363 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
