This is an archive of the discontinued LLVM Phabricator instance.

[MLIR] Add pass to deduplicate functions
ClosedPublic

Authored by frgossen on Feb 24 2023, 8:17 AM.

Details

Summary

Deduplicate functions that are equivalent in all aspects but their symbol name.
The pass chooses one representative per equivalence class, erases the remainder, and updates function calls accordingly.

Depends On D144735

Diff Detail

Event Timeline

frgossen created this revision.Feb 24 2023, 8:17 AM
frgossen requested review of this revision.Feb 24 2023, 8:17 AM
pifon2a accepted this revision.Feb 26 2023, 11:08 PM
pifon2a added inline comments.
mlir/lib/Dialect/Func/Transforms/DuplicateFunctionElimination.cpp
15–16

can it be moved to the anonymous namespace below?

mlir/test/Dialect/Func/duplicate-function-elimination.mlir
24–25

maybe add
CHECK-NOT: func @also_identity
CHECK-NOT: func @yet_another_identity

26–28

nit: CHECK-COUNT-3?

This revision is now accepted and ready to land.Feb 26 2023, 11:08 PM
frgossen marked 3 inline comments as done.Feb 27 2023, 7:57 AM

Thanks!

frgossen updated this revision to Diff 500793.Feb 27 2023, 7:59 AM

Address comments

This revision was landed with ongoing or failed builds.Feb 27 2023, 8:00 AM
This revision was automatically updated to reflect the committed changes.
rriddle added inline comments.Feb 27 2023, 10:22 AM
mlir/lib/Dialect/Func/Transforms/DuplicateFunctionElimination.cpp
12

Please switch this to using namespace mlir; instead of wrapping the file in a namespace.

22

Can you drop this newline here?

24

Please drop trivial braces (throughout the patch).

97

This will be incorrect for recursively nested functions, this should be a single level walk.

107

This also looks incorrect in the fast of nested modules. Can you fix+add tests?

mlir/test/Dialect/Func/duplicate-function-elimination.mlir
271

Are these tests really worth having? Can we trim this down to a manageable set that tests just what is needed?

What is specific to funcop vs the more general FunctionalOpInterface?

mehdi_amini added inline comments.Mar 6 2023, 7:23 PM
mlir/lib/Dialect/Func/Transforms/DuplicateFunctionElimination.cpp
109

I am not convinced by the correctness of this:

  1. I don’t see where you’re checking for visibility? (Public function can’t be removed)
  2. while updating call sites is fine, removing the function does not seem safe if you can’t guarantee there is any reference left (other than call)

I would rather leave the “unused” function around and invoke symbol-dce

frgossen marked 7 inline comments as done.Mar 20 2023, 2:08 PM

Thanks for the comments. I addressed them in https://reviews.llvm.org/D146456.

What is specific to funcop vs the more general FunctionalOpInterface?

I guess it could be generalized when needed.

mlir/lib/Dialect/Func/Transforms/DuplicateFunctionElimination.cpp
22

Unfortunately the line is one char too long :/

mlir/test/Dialect/Func/duplicate-function-elimination.mlir
271

The nested aspect is definitely worth having. I guess it could be level less but is that worth changing now?

I rather not write code that is over-restrictive unnecessarily (if you think about it, the entirety of MLIR exists because we generalize early, otherwise we'd have rebuilt LLVM or XLA ;) )

We have a significant amount of code written for func::FuncOp, but that predates the existence of the FunctionalInterface. I'm not aware of counter example to the "prefer FunctionalInterface instead of the concrete FuncOp when possible" guideline I have in mind at the moment, maybe @rriddle sees any?