This is an archive of the discontinued LLVM Phabricator instance.

[ODS] Use 'is' instead of 'get' to prefix optional UnitAttr accessors
Needs ReviewPublic

Authored by amandatang on May 31 2023, 10:53 AM.

Diff Detail

Event Timeline

amandatang created this revision.May 31 2023, 10:53 AM
amandatang requested review of this revision.May 31 2023, 10:53 AM
amandatang edited the summary of this revision. (Show Details)May 31 2023, 10:57 AM

Nice, overall looks good and reads nicer.

mlir/include/mlir/TableGen/Operator.h
348

Why can't this just be getGetterName and these merged? Computational efficiency?

mlir/lib/Dialect/Linalg/Transforms/ConvertToDestinationStyle.cpp
304

Should this just be isNofold() ? (not sure why attr post fix, not specific to your change though so just OOC)

mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp
1022

Lets end with s/.'/; method will be removed 2023-06-23/

and could send a PR to https://github.com/llvm/mlir-www/blob/main/website/content/deprecation/_index.md to add it there too.

1382

Could you tag all of these with same date so it is easier to find ?

One thing that's kind of popped up while reading the review is that this going to skew towards attributes with certain naming schemes, which needs to be documented. This is a bit because I feel that 'is' doesn't read well for a number of different cases.

mehdi_amini added inline comments.May 31 2023, 12:08 PM
mlir/lib/Conversion/NVGPUToNVVM/NVGPUToNVVM.cpp
291

This does not seem desirable to me that the accessor for getting the attribute name is prefixed with is instead of get.

amandatang added inline comments.May 31 2023, 2:37 PM
mlir/include/mlir/TableGen/Operator.h
348

Yes, the unit attribute check is unnecessary for operands, results and other types. Open to suggestions to improve this logic though.

mlir/lib/Dialect/Linalg/Transforms/ConvertToDestinationStyle.cpp
304

Probably. Not sure where this specific instance of the nofold attribute accessor is defined/generated though.

One thing that's kind of popped up while reading the review is that this going to skew towards attributes with certain naming schemes, which needs to be documented. This is a bit because I feel that 'is' doesn't read well for a number of different cases.

Is this just a matter of updating the documentation/style guide or is there a bigger problem regarding naming of unit attributes currently and in the future?

mlir/lib/Conversion/NVGPUToNVVM/NVGPUToNVVM.cpp
291

Reverting the changes for the attribute name getters

amandatang updated this revision to Diff 527650.Jun 1 2023, 3:34 PM

Reverted changes for AttrName getters and fixed tests

amandatang marked 3 inline comments as done.Jun 1 2023, 3:37 PM
aartbik added inline comments.Jun 1 2023, 8:26 PM
mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorCodegen.cpp
828

related to what others said, this reads weird now

hasInserts() would be nice if want to start with a verb

amandatang updated this revision to Diff 528570.Jun 5 2023, 1:59 PM

Use one getGetterName method and logic to handle attributes beginning with has

amandatang marked 2 inline comments as done.Jun 5 2023, 2:02 PM
amandatang added inline comments.Jun 5 2023, 2:42 PM
mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorCodegen.cpp
828

There are other cases in addition to attribute names that start with "has" where the additional "is" prefix makes it read weird. Handling each case individually does not guarantee consistency and probably isn't feasible. It may be better to update the style guide, so the programmer can ensure proper naming conventions.

jpienaar added inline comments.
mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorCodegen.cpp
828

is is a verb. But this goes to River's point below: the prefix works better if one follows naming convention accounting for it.

For boolean accessors is and has are common conventions for prefixing boolean return functions. @lattner commented in the linked issue that in LLVM is is the prefix convention followed.

So 4 options here:

  1. Keep the consistent with accessors but inconsistent with manually written code get prefix;
  2. Add no prefix and leave it up to user (e.g., just convert to lowerCamel)
  3. Enable variable prefix for them ({is, has}, not sure if others are needed ... may ?)
  4. Consistently use is as prefix for boolean return functions

For (4) an entry is added to ODS style guide and folks update so that it reads more naturally.

kuhar resigned from this revision.Jun 11 2023, 1:14 PM

Would it be possible/reasonable to default to "is" and then allow another ODS property to overload it with an arbitrary word like "has"?

Pull new changes and fix build failure

Would it be possible/reasonable to default to "is" and then allow another ODS property to overload it with an arbitrary word like "has"?

It would yes, but there was opposition to enabling accessors to be customized previously (https://github.com/llvm/llvm-project/issues/51258). This is option (3) above though.

It is unclear how much option (3) benefits vs (2) e.g., with (2) you'd have "has_padding" or "is_continuous" in the printed IR rather than "padding" and "continuous", but no need to do anything in ODS or introduce new class for UnitAttr instances to instantiate. And I almost feel that is more readable. We could also do variant of (2) where it is required that there be a prefix in the Attribute ([a-z]*_ or perhaps just an allowed set), else it gets an is.

kiranchandramohan resigned from this revision.Jun 24 2023, 2:29 AM