OpAdaptor::verify performs string lookups on an attribute dictionary. By
calling OpAdaptor::verify, Op::verify is not able to use cached attribute
identifiers for faster lookups.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Update on binary size: this change actually reduces binary size slightly. The majority of *OpAdaptor::verify functions are stripped because they are never called.
Trying to create a common verify method which both *Op and *OpAdaptor call into reduces binary size but not as much as just leaving both functions separate. No visible performance impact, but it does make OpDefinitionsGen.cpp messier.
Thanks for checking on size, looks good thanks
mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp | ||
---|---|---|
2138 | I'm not sure I follow why opRequired check is needed here - this could show a bug elsewhere |
mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp | ||
---|---|---|
2138 | When emitting a verifier inside an op, attribute lookups are (*this)->getAttr({0}AttrName()) and {0} must be the "getter" name of the attribute, e.g. operand_segment_sizes -> getOperandSegmentSizes. The generated file won't compile without this check. |
mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp | ||
---|---|---|
2138 | For genNativeTraitAttrVerifier, I see attrGet being opGetAttr and adaptorGetAttr, and it seems that whether or not to use adaptorGetAttr or opGetAttr seems to be the same as opRequired here - and there is clear linkage between opGetAttr and adaptorGetAttr and op.getGetterName usage or not. So is that true? That if opRequired is specified then we have to use opGetAttr and vice versa. And then do we need to have both be specified at call sites? |
Review comments.
As for compile time, the effects of this change alone are pretty muted (<1%),
but coupled with subrange lookup (upcoming patch) the effects become more
noticeable (~2%).