[mlir][CAPI] Allow specifying pass manager anchor

[rkayaith]

Summary

This adds a new function for creating pass managers that takes an
argument for the anchor string.

[rkayaith]

description

[mehdi_amini]

I'm a bit hesitant if we should rename C API in this kind of case to make sure the build breakage is visible through the symbol name change?

[rkayaith]

I could rename it to something like mlirPassManagerCreateWithAnchor but it's a bit unfortunate, mlirPassManagerCreate feels like the "right" name. Or maybe there should be both: mlirPassManagerCreate which uses the default anchor (builtin.module for now, but should probably be changed to any) and mlirPassManagerCreateWithAnchor with the anchor argument?

And I suppose the same thing about renaming applies to D136403?

[mehdi_amini]

In D136404#3881445, @rkayaith wrote:

I could rename it to something like mlirPassManagerCreateWithAnchor but it's a bit unfortunate, mlirPassManagerCreate feels like the "right" name. Or maybe there should be both: mlirPassManagerCreate which uses the default anchor (builtin.module for now, but should probably be changed to any) and mlirPassManagerCreateWithAnchor with the anchor argument?

And I suppose the same thing about renaming applies to D136403?

Yes, I'd wait for @ftynse and @stellaraccident to chime in here.

[ftynse]

I don't have a strong opinion. We don't (yet) offer any sort of API stability guarantees at this level, so just changing it is fine. There will be a compiler error, it's not like changing the type from one pointer to another. On the other hand, having mlirPassManagerCreate to work on builtin.module sounds like a reasonable default and we can have a more verbose mlirPassManagerCreateOnOperation that also needs a more verbose argument.

[stellaraccident]

In D136404#3885547, @ftynse wrote:

I don't have a strong opinion. We don't (yet) offer any sort of API stability guarantees at this level, so just changing it is fine. There will be a compiler error, it's not like changing the type from one pointer to another. On the other hand, having mlirPassManagerCreate to work on builtin.module sounds like a reasonable default and we can have a more verbose mlirPassManagerCreateOnOperation that also needs a more verbose argument.

I concur with Alex. I have a slight preference for the mlirPassManagerCreateOnOperation approach but wouldn't insist on it.

[rkayaith]

create new function, mlirPassManagerCreateOnOperation, instead of changing the existing one

mlir/include/mlir-c/Pass.h

 DEFINE_C_API_STRUCT(MlirOpPassManager, void);
 
 #undef DEFINE_C_API_STRUCT
 
 //===----------------------------------------------------------------------===//
 // PassManager/OpPassManager APIs.
 //===----------------------------------------------------------------------===//
 
-/// Create a new top-level PassManager.
+/// Create a new top-level PassManager with the default anchor.
 MLIR_CAPI_EXPORTED MlirPassManager mlirPassManagerCreate(MlirContext ctx);
 
+/// Create a new top-level PassManager anchored on `anchorOp`.
+MLIR_CAPI_EXPORTED MlirPassManager
+mlirPassManagerCreateOnOperation(MlirContext ctx, MlirStringRef anchorOp);
+
 /// Destroy the provided PassManager.
 MLIR_CAPI_EXPORTED void mlirPassManagerDestroy(MlirPassManager passManager);
 
 /// Checks if a PassManager is null.
 static inline bool mlirPassManagerIsNull(MlirPassManager passManager) {
   return !passManager.ptr;
 }
 

mlir/lib/CAPI/IR/Pass.cpp

 //===----------------------------------------------------------------------===//
 // PassManager/OpPassManager APIs.
 //===----------------------------------------------------------------------===//
 
 MlirPassManager mlirPassManagerCreate(MlirContext ctx) {
   return wrap(new PassManager(unwrap(ctx)));
 }
 
+MlirPassManager mlirPassManagerCreateOnOperation(MlirContext ctx,
+                                                 MlirStringRef anchorOp) {
+  return wrap(new PassManager(unwrap(ctx), unwrap(anchorOp)));
+}
+
 void mlirPassManagerDestroy(MlirPassManager passManager) {
   delete unwrap(passManager);
 }
 
 MlirOpPassManager
 mlirPassManagerGetAsOpPassManager(MlirPassManager passManager) {
   return wrap(static_cast<OpPassManager *>(unwrap(passManager)));
 }

mlir/test/CAPI/pass.c

 
 static void dontPrint(MlirStringRef str, void *userData) {
   (void)str;
   (void)userData;
 }
 
 void testPrintPassPipeline() {
   MlirContext ctx = mlirContextCreate();
-  MlirPassManager pm = mlirPassManagerCreate(ctx);
+  MlirPassManager pm = mlirPassManagerCreateOnOperation(
+      ctx, mlirStringRefCreateFromCString("any"));
   // Populate the pass-manager
   MlirOpPassManager nestedModulePm = mlirPassManagerGetNestedUnder(
       pm, mlirStringRefCreateFromCString("builtin.module"));
   MlirOpPassManager nestedFuncPm = mlirOpPassManagerGetNestedUnder(
       nestedModulePm, mlirStringRefCreateFromCString("func.func"));
   MlirPass printOpStatPass = mlirCreateTransformsPrintOpStats();
   mlirOpPassManagerAddOwnedPass(nestedFuncPm, printOpStatPass);
 
   // Print the top level pass manager
-  //      CHECK: Top-level: builtin.module(
+  //      CHECK: Top-level: any(
   // CHECK-SAME:   builtin.module(func.func(print-op-stats{json=false}))
   // CHECK-SAME: )
   fprintf(stderr, "Top-level: ");
   mlirPrintPassPipeline(mlirPassManagerGetAsOpPassManager(pm), printToStderr,
                         NULL);
   fprintf(stderr, "\n");
 
   // Print the pipeline nested one level down