This is an archive of the discontinued LLVM Phabricator instance.

[mlir][ods] Add codegen support for custom verifiers (for attributes and types)
AbandonedPublic

Authored by jfurtek on May 20 2022, 5:27 PM.

Details

Summary

mlir-tblgen has enough information to automatically generate the verify()
function for some attributes and types. (The canonical example might be checking
whether or not an integer value is one of the specified enum values for enum
attributes.)

Previously, the genVerifyDecl field was used to instruct mlir-tblgen to
generate a declaration for the verify() function, and users would be required
to provide the implementation. This diff adds the capability to specify a
verify() function directly in the mlir-tblgen input (ODS) file.

This is accomplished by duplicating the existing mlir-tblgen logic for code
generation of get() methods via the builders field, and modifying it
slightly to generate verify() methods. As such:

  • the TablgGen Builder class was renamed to MethodSpec (for "method specification") to reflect a more general usage
  • a verifiers field was added to the AttrOrTypeDef base class
  • the EnumAttr class was modified to provide a custom verify() implementation for integer and bit enum attributes
  • tests were added for integer and bit enums to verify that getChecked() will return a null attribute for invalid enum values

The existing genVerifyDecl behavior is maintained, and attributes/types will
only behave differently if a non-empty verifiers field is present.

This functionality is expected to be used by a subsequent diff that adds Python
bindings for enums, and will also be used for fastmath support in the
Arithmetic dialect.

Diff Detail

Event Timeline

jfurtek created this revision.May 20 2022, 5:27 PM
jfurtek requested review of this revision.May 20 2022, 5:27 PM

Did you consider adding verification support to AttrOrTypeParameter instead? That would be more inline with how verification is done for operations.

Did you consider adding verification support to AttrOrTypeParameter instead? That would be more inline with how verification is done for operations.

I had not considered that.

So this scheme would allow each AttrOrTypeParameter in ODS to provide verifier code, and then tblgen can generate a verify() function for the attribute/type that verifies each AttrOrTypeParameter, returning success() only if all succeed? IIUC, this differs slightly from operations in that MyOp::verifyInvariants() is run on an operation that already exists, whereas for attributes MyAttr::verify() is called before creation.

I think that your approach makes more sense - I just want to make sure I understand before implementing...

Did you consider adding verification support to AttrOrTypeParameter instead? That would be more inline with how verification is done for operations.

I had not considered that.

So this scheme would allow each AttrOrTypeParameter in ODS to provide verifier code, and then tblgen can generate a verify() function for the attribute/type that verifies each AttrOrTypeParameter, returning success() only if all succeed?

I think that your approach makes more sense - I just want to make sure I understand before implementing...

Yeah, what you describe there is what I had in mind.

IIUC, this differs slightly from operations in that MyOp::verifyInvariants() is run on an operation that already exists, whereas for attributes MyAttr::verify() is called before creation.

Indeed, given that Attributes/Types are immortal/unique'd, verification happens prior to creation.

jfurtek abandoned this revision.May 25 2022, 7:40 AM

OK - I think I understand. Let me take another pass at this. Thanks for the help.