Page MenuHomePhabricator

[mlir] Optimize Op definitions and registration to optimize for code size

Authored by rriddle on Oct 26 2020, 3:36 PM.



This revision refactors the base Op/AbstractOperation classes to reduce the amount of generated code size when defining a new operation. The current scheme involves taking the address of functions defined directly on Op and Trait classes. This is problematic because even when these functions are empty/unused we still result in these functions being defined in the main executable. In this revision, we switch to using SFINAE and template type filtering to remove remove functions that are not needed/used. For example, if an operation does not define a custom print method we shouldn't define a templated printAssembly method for it. The same applies to parsing/folding/verification/etc. This dropped MLIR code size for a large downstream library by ~10%(~1 mb in an opt build).

Depends On D90087

Diff Detail

Event Timeline

rriddle created this revision.Oct 26 2020, 3:36 PM
rriddle requested review of this revision.Oct 26 2020, 3:36 PM
rriddle updated this revision to Diff 300820.Oct 26 2020, 3:54 PM

Remove use of std::disjunction as it is only in C++17.

jpienaar accepted this revision.Mon, Nov 2, 10:33 AM

This looks good in general, thanks


I seem to recall that we did the part on the left due to what happens if we add like ~2000 ops in some SAN builds & fold. Is that no longer an issue?



This revision is now accepted and ready to land.Mon, Nov 2, 10:33 AM
mehdi_amini accepted this revision.Mon, Nov 2, 10:48 AM

Nice template use! ;)


What is this 4 / comment?

rriddle updated this revision to Diff 302391.Mon, Nov 2, 1:38 PM
rriddle marked 3 inline comments as done.

Resolve comments

rriddle added inline comments.Mon, Nov 2, 2:21 PM

This was problematic before because we would end up creating ~2000 instances of AbstractOperation on the stack, given we had:

        0, (addOperation(AbstractOperation::get<Args>(*this)), 0)...};

where AbstractOperation::get returned an instance of AbstractOperation. That isn't the case here given that we aren't creating any objects, and the single parameter(Dialect &) is shared across all of the calls.


I was just using 4 to create different sections for the various functions from AbstractOperation.

This revision was landed with ongoing or failed builds.Mon, Nov 2, 2:46 PM
This revision was automatically updated to reflect the committed changes.