This is an archive of the discontinued LLVM Phabricator instance.

Add a basic C API for the MLIR PassManager as well as a basic TableGen backend for creating passes
ClosedPublic

Authored by mehdi_amini on Nov 2 2020, 9:15 PM.

Details

Summary

This is exposing the basic functionalities (create, nest, addPass, run) of
the PassManager through the C API in the new header: include/mlir-c/Pass.h.

In order to exercise it in the unit-test, a basic TableGen backend is
also provided to generate a simple C wrapper around the pass
constructor. It is used to expose the libTransforms passes to the C API.

Diff Detail

Event Timeline

mehdi_amini created this revision.Nov 2 2020, 9:15 PM
mehdi_amini requested review of this revision.Nov 2 2020, 9:15 PM
stellaraccident accepted this revision.Nov 2 2020, 11:12 PM

Naming/style/doc nits.

I am interested to see where you take the pass constructor generation/registry/etc but don't need to know more for this patch.

mlir/include/mlir-c/Pass.h
55

Here and below: s/pass_manager/passManager/

63

Possibly add a comment to the end: To create a second-level nested pass manager, use ...other function....

64

I had to read this several times and refer to the C++ documentation to grok. I think that I would have understood it better if the name of this function read like a factory/constructor. e.g. mlirPassManagerNestNew or mlirPassManagerCreateNested

65

s/operation/operationName/ ?

75

Ditto on naming style with the top-level nest. Also, I think this makes more sense directly under mlirPassManagerNest.

76

s/operation/operationName/ ?

mlir/include/mlir-c/Transforms.h
19

I believe that this is the first time that a public mlir-c header file includes something from the mlir tree. That is going to be unfortunate when it comes to packaging and installation (i.e. only wanting to expose C headers).

I'm fine to wait and see what you do here if you are just staging things to get started. Possibly drop a TODO.

mlir/lib/CAPI/IR/Pass.cpp
28

s/pass_manager/passManager/

This revision is now accepted and ready to land.Nov 2 2020, 11:12 PM
mehdi_amini added inline comments.Nov 2 2020, 11:21 PM
mlir/include/mlir-c/Pass.h
64

Isn't "Create" conveying a notion of ownership? The returned pass manager here is attached to the provided one.

mlir/include/mlir-c/Transforms.h
19

This is purely a CMake question at the moment: our TableGen plumbing does not allow to emit the output somewhere else than where the .td is located.

mehdi_amini marked 3 inline comments as done.Nov 3 2020, 1:11 AM

Address comments

Clang-format

ftynse accepted this revision.Nov 3 2020, 1:27 AM

LGTM provided that we discuss how to generalize the tablegen infra and file organization wrt individual libraries.

mlir/include/mlir-c/Transforms.h
19

We will likely need to restructure Tablegen infra a bit. I was also pondering the question whether we want to have Tablegen backends for bindings to live under tools/mlir-tblgen or under bindings/.

mlir/include/mlir/Transforms/CAPI.h
9–14 ↗(On Diff #302505)

Do we actually need this file? There is only one user currently, and this user is a test, so I wouldn't mind if it included .inc directly. We don't have a CAPI.h under IR

mlir/lib/Transforms/CAPIPasses.cpp
1 ↗(On Diff #302505)

So far, we tried not to add C API related files to the "main" libraries. The risk is to have C-related functionality creep into C++ and make it hard to separate the two. I suppose this is due to Tablegen setup not being able to emit files elsewhere, so I am happy to discuss the future layering.

mlir/test/CAPI/pass.c
51

Nit: EXIT_FAILURE ?

86

Nit: camelBack

102

Nit: 80 cols

mlir/tools/mlir-tblgen/PassCAPIGen.cpp
41

Ultra-nit: add a trailing dot to the comment.

Harbormaster completed remote builds in B77373: Diff 302505.
mehdi_amini marked 4 inline comments as done.

Address Alex's comments

Fix clang-tidy header guards

mehdi_amini added inline comments.Nov 3 2020, 2:14 AM
mlir/include/mlir/Transforms/CAPI.h
9–14 ↗(On Diff #302505)

Yes this file is bogus, deleting

mlir/lib/Transforms/CAPIPasses.cpp
1 ↗(On Diff #302505)

Moved to lib/CAPI now

mehdi_amini added inline comments.Nov 3 2020, 1:39 PM
mlir/include/mlir-c/Pass.h
64

Ping on this naming question?
@ftynse an opinion?

mlir/include/mlir-c/Transforms.h
19

I am not sure, do you want to address this now?

ftynse added inline comments.Nov 3 2020, 1:51 PM
mlir/include/mlir-c/Pass.h
64

Indeed, Create indicates ownership transfer to the caller. We use Get when there is no ownership transfer, e.g. for types and attributes that may be allocated under the hood. Not sure if is the best choice here.

mlir/include/mlir-c/Transforms.h
19

Nah, just mentioning that it is something we need to think about eventually.

mehdi_amini added inline comments.Nov 3 2020, 1:57 PM
mlir/include/mlir-c/Pass.h
64

What about mlirPassManagerGetNested() or mlirPassManagerGetNestedUnder() ?

Rename mlirOpPassManagerGetNestedUnder

stellaraccident accepted this revision.Nov 3 2020, 10:19 PM
stellaraccident added inline comments.
mlir/include/mlir-c/Pass.h
64

I like mlirPassManagerGetNested(). "Get" as the verb makes more sense to me vs "nest".

This revision was landed with ongoing or failed builds.Nov 3 2020, 10:37 PM
This revision was automatically updated to reflect the committed changes.

Hi @mehdi_amini , thank you for working on this!

Sadly This has caused our Flang buildbots to start failing: http://lab.llvm.org:8011/#/builders/33/builds/478

I'm guessing that you haven't tested with BUILD_SHARED_LIBS? The fix seemed trivial and took the liberty of pushing a fix: https://github.com/llvm/llvm-project/commit/d007bbd986d9ab004c34efaca27aff4a7633b9e9.

I hope that people don't mind. It's not clear to me _why_ static builds are fine (even without the fix). Perhaps I missed something obvious?

Also, if you do mind such ad-hoc fixes, that's a very valuable feedback for me :)

mehdi_amini added a comment.EditedNov 4 2020, 11:56 AM

Sadly This has caused our Flang buildbots to start failing: http://lab.llvm.org:8011/#/builders/33/builds/478

I'm guessing that you haven't tested with BUILD_SHARED_LIBS?

Indeed!

The fix seemed trivial and took the liberty of pushing a fix: https://github.com/llvm/llvm-project/commit/d007bbd986d9ab004c34efaca27aff4a7633b9e9.

Thanks! In the future, if your bot is broken and the fix isn't trivial, feel free to push a revert for my patch. Getting the bot back to green is the priority of course.

I hope that people don't mind. It's not clear to me _why_ static builds are fine (even without the fix). Perhaps I missed something obvious?

The reasons why this is working in static library is that linking is delayed to the final binary: as long as the missing dependency is also present in the final binary link it'll be fine.
With the shared library build, for each library we link it in isolation and resolve the dependencies at this point.

The reasons why this is working in static library is that linking is delayed to the final binary: as long as the missing dependency is also present in the final binary link it'll be fine.
With the shared library build, for each library we link it in isolation and resolve the dependencies at this point.

This makes a lot of sense, thanks for explaining!