Add SCF Dialect C API

[stellaraccident]

mlir/include/mlir-c/SCFDialect.h

29

I would like to discuss more how we scale dialect registration: three loose entryoints for such things makes it really awkward to treat generically on any way. Personally, I'd rather see a MlirDialectRegistration struct that provides function pointers for load/register and the namespace. Then I'd like to see one function for obtaining a pointer to that struct. This would help interop with other APIs, allowing us to have simple, opaque calls to get the registration info and then an API to apply it generically. It would also get us closer to being able to do dynamic discovery of dialects.

In any case: I'm not opposed to doing this one more this way but would like to bump this up to discuss approach before we go much further.

[GeorgeLyon]

I very much agree @stellaraccident. I would even go one step further and say there should be an mlirGetDialectByNamespace(MlirStringRef) function to return this structure, which we can enable using static constructors (even though they are evil, this would be a very nice way to not have to create a CAPI for every dialect). For the record, in the Swift bindings I use "Dialect" to mean what you refer to as "Dialect Registration" and "Dialect Instance" to refer to the thing returned by getOrLoad. I also don't currently understand how Dialect Instances are useful (and why we can't just have "Dialect Registration" be the only thing (hence "Dialect")

[GeorgeLyon]

That said, I think it would be nice to include a second dialect in the bindings as we work our way to a better system (and I need it for my test cases :-)

[mehdi_amini]

The code in this revision should all be part of the TableGen generated code and not manually written.

I would even go one step further and say there should be an mlirGetDialectByNamespace(MlirStringRef) function to return this structure, which we can enable using static constructors (even though they are evil, this would be a very nice way to not have to create a CAPI for every dialect).

I am quite strongly opposed to bringing global constructor based registration now that we eliminated it all from MLIR. I rather push this to the client if they want it and never provide this or relying on this kind of things with upstream APIs.

[GeorgeLyon]

The code in this revision should all be part of the TableGen generated code and not manually written.

I agree, but this isn't the case now. I (selfishly) don't think we should hold up this revision while we figure out a better system (since I would love to only use Standard and SCF in my Swift bindings and avoid pulling in every other dialect). We can continue searching for a better solution here: https://llvm.discourse.group/t/dialects-and-the-c-api/2306

[mehdi_amini]

I'll have to disagree here: it isn't clear why we're in a rush right now, unless we think it through and there is a significant amount of work to implement "the right thing", we shouldn't just move forward with something that we already know isn't right.

mlir/include/mlir-c/SCFDialect.h

+//===-- mlir-c/SCFDialect.h - C API for SCF dialect -----*- C -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
+// Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+//
+// This header declares the C interface for registering and accessing the
+// SCF dialect. A dialect should be registered with a context to make it
+// available to users of the context. These users must load the dialect
+// before using any of its attributes, operations or types. Parser and pass
+// manager can load registered dialects automatically.
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef MLIR_C_SCFDIALECT_H
+#define MLIR_C_SCFDIALECT_H
+
+#include "mlir-c/IR.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/** Registers the SCF dialect with the given context. This allows the
+ * dialect to be loaded dynamically if needed when parsing. */
+MLIR_CAPI_EXPORTED void mlirContextRegisterSCFDialect(MlirContext context);
+
+/** Loads the SCF dialect into the given context. The dialect does _not_
+ * have to be registered in advance. */
+MLIR_CAPI_EXPORTED MlirDialect mlirContextLoadSCFDialect(MlirContext context);
+
+/// Returns the namespace of the SCF dialect, suitable for loading it.
+MLIR_CAPI_EXPORTED MlirStringRef mlirSCFDialectGetNamespace();
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif // MLIR_C_SCFDIALECT_H

mlir/lib/CAPI/CMakeLists.txt

 add_subdirectory(IR)
 add_subdirectory(Registration)
+add_subdirectory(SCF)
 add_subdirectory(Standard)
 add_subdirectory(Transforms)
 
 
 ################################################################################
 # libMLIRPublicAPI shared library/DLL.
 ################################################################################
 

mlir/lib/CAPI/SCF/CMakeLists.txt

+add_mlir_public_c_api_library(MLIRCAPISCF
+  SCFDialect.cpp
+
+  LINK_LIBS PUBLIC
+  MLIRCAPIIR
+  MLIRSCF
+)

mlir/lib/CAPI/SCF/SCFDialect.cpp

+//===- SCFDialect.cpp - C Interface for SCF dialect -------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include "mlir-c/SCFDialect.h"
+#include "mlir-c/IR.h"
+#include "mlir/CAPI/IR.h"
+#include "mlir/CAPI/Support.h"
+#include "mlir/Dialect/SCF/SCF.h"
+
+void mlirContextRegisterSCFDialect(MlirContext context) {
+  unwrap(context)->getDialectRegistry().insert<mlir::scf::SCFDialect>();
+}
+
+MlirDialect mlirContextLoadSCFDialect(MlirContext context) {
+  return wrap(unwrap(context)->getOrLoadDialect<mlir::scf::SCFDialect>());
+}
+
+MlirStringRef mlirSCFDialectGetNamespace() {
+  return wrap(mlir::scf::SCFDialect::getDialectNamespace());
+}