This is an archive of the discontinued LLVM Phabricator instance.

[mlir:ODS] Deprecate Op parser/printer fields in favor of a new hasCustomAssemblyFormat field
ClosedPublic

Authored by rriddle on Feb 4 2022, 8:51 PM.

Details

Summary

Currently if an operation wants a C++ implemented parser/printer, it specifies inline
code blocks. This is quite problematic for various reasons, e.g. it requires defining
C++ inside of Tablegen which is discouraged when possible, but mainly because
nearly all usages simply forward to static functions (e.g. static void parseSomeOp(...))
with users devising their own standards for how these are defined.

This commit adds support for a hasCustomAssemblyFormat bit field that specifies if
a C++ parser/printer is needed, and when set to 1 declares the parse/print methods for
operations to override. For migration purposes, the existing behavior is untouched. Upstream
usages will be replaced in a followup to keep this patch focused on the new implementation.

Diff Detail

Event Timeline

rriddle created this revision.Feb 4 2022, 8:51 PM
rriddle requested review of this revision.Feb 4 2022, 8:51 PM

hasCppAssemblyFormat was the best name my brain could come up with quickly, happy to shift it to something else.

mehdi_amini accepted this revision.Feb 4 2022, 10:54 PM

I don't have a better naming suggestion just now!

This revision is now accepted and ready to land.Feb 4 2022, 10:54 PM

Awesome, very excited about this. In terms of name, WDYT about hasCustomAssemblyFormat? You're right that Cpp is more technically correct, but I think we generally call manually written C++ as the "custom" stuff.

The reason I didn't suggest hasCustomAssemblyFormat is that it puts the declarative assembly form as a "non custom format" somehow. But since this is all within ODS this may not be that confusing.

The reason I didn't suggest hasCustomAssemblyFormat is that it puts the declarative assembly form as a "non custom format" somehow. But since this is all within ODS this may not be that confusing.

This is also why I didn't use that name initially. We refer to any derived assembly format as a being a "custom assembly format" (including the declarative form). Maybe this doesn't matter given hasCustomAssemblyFormat/assemblyFormat can just be treated as two ways to get a custom assembly format (and the Custom here is limited to an ODS context). Either way renaming this in the future is trivial (it's just a field).

rriddle updated this revision to Diff 406275.Feb 6 2022, 1:39 PM
rriddle retitled this revision from [mlir:ODS] Deprecate Op parser/printer fields in favor of a new hasCppAssemblyFormat field to [mlir:ODS] Deprecate Op parser/printer fields in favor of a new hasCustomAssemblyFormat field.
rriddle edited the summary of this revision. (Show Details)
jpienaar accepted this revision.Feb 7 2022, 8:40 AM
jpienaar added a subscriber: jpienaar.
jpienaar added inline comments.
mlir/include/mlir/IR/OpBase.td
2448–2449

Could you emit a warning from ODS when these are set to warn folks that these are deprecated?

This revision was automatically updated to reflect the committed changes.
rriddle marked an inline comment as done.