Page MenuHomePhabricator

[mlir] Add a DCE pass for dead symbols.
ClosedPublic

Authored by rriddle on Jan 9 2020, 2:39 PM.

Details

Summary

This pass deletes all symbols that are found to be unreachable. This is done by computing the set of operations that are known to be live, propagating that liveness to other symbols, and then deleting all symbols that are not within this live set.

Diff Detail

Event Timeline

rriddle created this revision.Jan 9 2020, 2:39 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 9 2020, 2:39 PM

Unit tests: pass. 61736 tests passed, 0 failed and 779 were skipped.

clang-tidy: fail. Please fix clang-tidy findings.

clang-format: pass.

Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml

rriddle updated this revision to Diff 240422.Jan 26 2020, 1:15 AM

Rebase on use list refactoring.

Unit tests: pass. 62198 tests passed, 0 failed and 815 were skipped.

clang-tidy: pass.

clang-format: pass.

Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml

Pre-merge checks is in beta. Report issue. Please join beta or enable it for your project.

Do we need a full separate pass structure for mlir or is there some sharing we can do here as this (at the IR level) is encompassed by GlobalDCE.

fhahn added a subscriber: fhahn.Jan 27 2020, 6:55 PM

Do we need a full separate pass structure for mlir or is there some sharing we can do here as this (at the IR level) is encompassed by GlobalDCE.

We do need our own pass in MLIR for a couple of reasons:

  1. There are many targets of MLIR that don't directly lower to LLVM(e.g. some non programming language front-ends).
  2. Symbols are used at many different abstraction levels, and having the ability to DCE at each is important and powerful.

Note that even if these abstractions do eventually lower to LLVM, sometimes the 'symbol' does not have a direct representation in LLVM. For example, a Dialect in MLIR may have a 'global variable' like operation that is eventually transformed into a buffer when compiling for a specific device. In situations like those, the resultant code wouldn't contain a global in the traditional sense.

  1. MLIR supports nested references. A "module" isn't constrained to be a module like in the LLVM sense. Modules(and module like operations) can be arbitrarily nested within each other.

I've looked a bit at GlobalDCE, but at this time I'm not sure how much sharing we can do. This pass is meant to be generic, i.e. agnostic to the specific design choices of a given dialect, and the LLVM definition of globals/linkage/visibility does not generalize across all of the different users.

Did you have any specific ideas in mind for how/what things could be shared?

mehdi_amini accepted this revision.Jan 27 2020, 8:08 PM
mehdi_amini added inline comments.
mlir/include/mlir/Transforms/Passes.h
130

Typo "have are"

mlir/lib/Transforms/SymbolDCE.cpp
105

typo: linakage

118

I'm not sure what this comment is trying to express here?

135

Could we get the uses after this step? This would reduce slightly the memory pressure during the recursion I think.

This revision is now accepted and ready to land.Jan 27 2020, 8:08 PM
rriddle updated this revision to Diff 240774.Jan 27 2020, 10:51 PM
rriddle marked 5 inline comments as done.

Resolve comments

Unit tests: unknown.

clang-tidy: unknown.

clang-format: unknown.

Build artifacts: diff.json, console-log.txt

Pre-merge checks is in beta. Report issue. Please join beta or enable it for your project.

This revision was automatically updated to reflect the committed changes.