[Mlir-commits] [mlir] [mlir][ODS] Optionally generate public C++ functions for type constraints (PR #104577)

[Matthias Springer]

================
@@ -1097,6 +1097,10 @@ def Builtin_UnrankedTensor : Builtin_Type<"UnrankedTensor", "unranked_tensor", [
 // VectorType
 //===----------------------------------------------------------------------===//
 
+def Builtin_VectorTypeElementType : AnyTypeOf<[AnyInteger, Index, AnyFloat]> {
----------------
matthias-springer wrote:

> Ignore everything not in the direct file that is being generated.

This sounds like a good strategy to me. I changed the implementation accordingly.

> I think we need to be careful about how/which ones get generated

A C++ function is generated only if the `cppFunctionName` field is set to a non-empty string. By default it is empty, so this entire process is on an opt-in basis.

> Could we have the one called from the other? Then the difference is just whether its exposed in header and perhaps whether instantiated in anonymous/impl namespace.

If a constraint calls a constraint via TableGen, it is fully inlined. E.g.: `AnyTypeOf<[I32, AnyTypeOf<[I16, I64]>]>` will generate a single C++ function that checks for `i32`, `i16`, `i64`. So this will work out of the box.

If a constraint calls a constraint via `CPred<"...">`, arbitrary C++ code can be specified and I'd say it's the user's responsibility to ensure that all needed C++ functions are pre-declared. By making sure that the corresponding header file (`.h` not `.inc.h`) is included in the `.cpp` file that contains the constraint definition. (Same as with ops that implement op interfaces: the user must include the `.h` file that declares the op interface in the `.h` file that contains the operation class.)


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