This is an archive of the discontinued LLVM Phabricator instance.

[mlir][OpGen] Cache Identifiers for known attribute names in AbstractOperation.
ClosedPublic

Authored by rriddle on Jun 11 2021, 6:10 PM.

Details

Summary

Operations currently rely on the string name of attributes during attribute lookup/removal/replacement, in build methods, and more. This unfortunately means that some of the most used APIs in MLIR require string comparisons, additional hashing(+mutex locking) to construct Identifiers, and more. This revision remedies this by caching identifiers for all of the attributes of the operation in its corresponding AbstractOperation. Just updating the autogenerated usages brings up to a 15% reduction in compile time, greatly reducing the cost of interacting with the attributes of an operation. This number can grow even higher as we use these methods in handwritten C++ code.

Methods for accessing these cached identifiers are exposed via <attr-name>AttrName methods on the derived operation class. Moving forward, users should generally use these methods over raw strings when an attribute name is necessary.

Diff Detail

Event Timeline

rriddle created this revision.Jun 11 2021, 6:10 PM
rriddle requested review of this revision.Jun 11 2021, 6:10 PM
mehdi_amini accepted this revision.Jun 11 2021, 7:34 PM

Awesome :)

This revision is now accepted and ready to land.Jun 11 2021, 7:34 PM
mehdi_amini added inline comments.Jun 11 2021, 7:35 PM
mlir/include/mlir/IR/OperationSupport.h
191

I don't know if this is the right place, but I feel we're missing some doc about how this all fit together

OOC what is the memory usage impact?

mlir/lib/IR/MLIRContext.cpp
727

So this initialized on construction rather than first use?

OOC what is the memory usage impact?

The TF model I tested on had an increase in memory usage of ~50kb, an IREE test I ran had an increase of ~28kb.

rriddle updated this revision to Diff 351988.Jun 14 2021, 1:45 PM
rriddle marked an inline comment as done.

rebase

rriddle marked an inline comment as done.Jun 14 2021, 1:45 PM
rriddle added inline comments.
mlir/include/mlir/IR/OperationSupport.h
191

Beefed up the description, PTAL.

mlir/lib/IR/MLIRContext.cpp
727

Yes. Initializing on first-use adds additional checks to the hot part of the code, which is something that we want. The way the revision is currently written, accessing a cached attribute name is effectively just a load from the AbstractOperation.

mehdi_amini accepted this revision.Jun 14 2021, 2:42 PM
rriddle updated this revision to Diff 353745.Jun 22 2021, 12:13 PM
rriddle marked an inline comment as done.

update

This change seems to break flang bulldbots.

The breaking buildbots:

flang-x86_64-windows: https://lab.llvm.org/staging/#/builders/179/builds/129

tools\flang\include\flang/Optimizer/Dialect/FIROps.h.inc(2324): error C2373: 'llvm::StringRef': redefinition; different type modifiers

ppc64le-flang-rhel-clang: https://lab.llvm.org/buildbot/#/builders/21/builds/17760

tools/flang/include/flang/Optimizer/Dialect/FIROps.h.inc:1615:32: error: functions that differ only in their return type cannot be overloaded
    static constexpr StringRef calleeAttrName() { return "callee"; }
                     ~~~~~~~~~ ^
tools/flang/include/flang/Optimizer/Dialect/FIROps.h.inc:1587:22: note: previous definition is here
  ::mlir::Identifier calleeAttrName() {
  ~~~~~~~~~~~~~~~~~~ ^

Sadly it also breaks my local build. I've tried reverting, but I'm getting merge conflicts, so that's not really an option. @rriddle , would you be able to fix this?

Sadly it also breaks my local build. I've tried reverting, but I'm getting merge conflicts, so that's not really an option. @rriddle , would you be able to fix this?

Yeah, should be fixed in the next 10-20 minutes. Sorry about that.

I was trying to fix the FIROps.td, but it is quite messy. We'll need a volunteer from the flang crowd for this: a lot of things should be defined in ODS are actually inline C++ in the .td and it conflicts with ODS (like here). It really does not seem maintainable.

Sent a minimal fix for check-flang in rG00c93d8801f1, but as Mehdi mentions the flang dialects need a good cleanup. There is a lot of C++ code within the .td files, and the code is using the raw API very frequently instead of the auto-generated ODS niceties (e.g. leading to an over-reliance on the string name of the attribute).

Many thanks for addressing this. I've not worked on FIROps.td myself, but I can see how the current design/usage might be troublesome. I'll bring this up, though I doubt that anyone will have the spare bandwidth just now. We do get community members volunteering every now and then and I'll keep this on my list of things to improve.

@mehdi_amini @rriddle I'll do a first pass to extract the big code parts out of the .td. If time permits I'll have a look at the raw API usage.

mehdi_amini added inline comments.Jul 12 2021, 5:54 PM
mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp
315

This function is unused right now?