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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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
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.
We do need our own pass in MLIR for a couple of reasons:
- There are many targets of MLIR that don't directly lower to LLVM(e.g. some non programming language front-ends).
- 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.
- 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?
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.
Typo "have are"