This is an archive of the discontinued LLVM Phabricator instance.

[mlir][ods] add mechanism for deprecating an `OpBuilder` in ODS
ClosedPublic

Authored by zero9178 on Feb 2 2023, 7:41 AM.

Details

Summary

This allows discouraging the use of specific build methods of an op by having TableGen generate C++ code, instructing the C++ compiler to warn on use of the build method.
The implementation uses the C++14 [[deprecated(...)]] for this purpose. I considered using LLVM_DEPRECATED`, but thought requiring a fix-it was not necassery, nor would the syntax in ODS have been very nice.

My motivation for this change is that in the future I'd like to deprecate the use build methods in the LLVM Dialect, not using explicit pointer types for ops such as llvm.load or llvm.alloca, which makes the code not future proof for opaque pointers. In-tree has to be clean first before I could commit such a change of course, but I thought the initial infrastructure change could already be submitted.

Diff Detail

Event Timeline

zero9178 created this revision.Feb 2 2023, 7:41 AM
zero9178 requested review of this revision.Feb 2 2023, 7:41 AM
Mogball added a comment.EditedFeb 2 2023, 10:21 AM

Was there a discourse discussion on this? I might've missed it. If there isn't, I'm 100% behind the rationale I think is behind this change, but I would still like to see it discussed.

mlir/lib/TableGen/Class.cpp
117

qq: I assume this is relatively portable?

zero9178 marked an inline comment as done.Feb 2 2023, 10:33 AM

Was there a discourse discussion on this? I might've missed it. If there isn't, I'm 100% behind the rationale I think is behind this change, but I would still like to see it discussed.

I am assuming you're talking about the switch to opaque pointers? No not yet, which is why it is also not part of this change. I am planning to post a PSA on the forum once the in-tree infrastructure is there. That mostly means having conversion passes work with both typed and opaque pointers (which is what I am currently working on).
Until then users of many upstream dialects are not able to switch fully.

That said, the build methods with explicit pointer types work with typed pointers as well so we could introduce the warning earlier if we wanted to to encourage downstream to use opaque pointer compatible GEPs, loads and alloca APIs. Do you think that'd be worth doing?

mlir/lib/TableGen/Class.cpp
117

Yes, this has been a feature since C++14, so well within our supported compilers.
This is also the Form used by LLVM_DEPRECATED for compilers that aren't clang.

The rationale makes sense to me, but in terms of ODS implementation have you considered defining a base "deprecated" class that is used as a mixin for OpBuilder? I'm a bit worried about adhoc additions of deprecation, and would prefer if we had a consistent story.

zero9178 updated this revision to Diff 494423.Feb 2 2023, 1:16 PM
zero9178 marked an inline comment as done.

Address review comments:
Create mixin that can be used for a consistent interface in ODS for marking an entity as deprecated within C++.
Also changes the interface from modifying OpBuilder to adding DeprecatedOpBuilder, making use of the above mixin. The reason for doing so is that OpBuilder are basically always used as anonymous defs, making it impossible to add a mixin to its instantiation. Therefore DeprecatedOpBuilder is used to keep the convenient syntax.
Other kinds of defs in ODS (such as Op ones) should not suffer from this problem. The mixin still has to be supported by the C++ code generator of a given entity, but I don't think there is any way around that.

rriddle accepted this revision.Feb 6 2023, 9:59 AM
This revision is now accepted and ready to land.Feb 6 2023, 9:59 AM

In there a nice spot in the ODS doc to add info for this?

zero9178 updated this revision to Diff 495468.Feb 7 2023, 4:09 AM

add documentation in Operations.md

jpienaar accepted this revision.Feb 7 2023, 7:41 AM

Nice, thanks