[all-commits] [llvm/llvm-project] f3df3b: [mlir] Add a utility class, ThreadLocalCache, for ...
River Riddle via All-commits
all-commits at lists.llvm.org
Fri Oct 16 12:09:33 PDT 2020
Branch: refs/heads/master
Home: https://github.com/llvm/llvm-project
Commit: f3df3b58e7dd7c400f9c18d16d92631823705ebd
https://github.com/llvm/llvm-project/commit/f3df3b58e7dd7c400f9c18d16d92631823705ebd
Author: River Riddle <riddleriver at gmail.com>
Date: 2020-10-16 (Fri, 16 Oct 2020)
Changed paths:
M mlir/include/mlir/Support/StorageUniquer.h
A mlir/include/mlir/Support/ThreadLocalCache.h
M mlir/lib/IR/MLIRContext.cpp
M mlir/lib/Support/StorageUniquer.cpp
Log Message:
-----------
[mlir] Add a utility class, ThreadLocalCache, for storing non static thread local objects.
(Note: This is a reland of D82597)
This class allows for defining thread local objects that have a set non-static lifetime. This internals of the cache use a static thread_local map between the various different non-static objects and the desired value type. When a non-static object destructs, it simply nulls out the entry in the static map. This will leave an entry in the map, but erase any of the data for the associated value. The current use cases for this are in the MLIRContext, meaning that the number of items in the static map is ~1-2 which aren't particularly costly enough to warrant the complexity of pruning. If a use case arises that requires pruning of the map, the functionality can be added.
This is especially useful in the context of MLIR for implementing thread-local caching of context level objects that would otherwise have very high lock contention. This revision adds a thread local cache in the MLIRContext for attributes, identifiers, and types to reduce some of the locking burden. This led to a speedup of several seconds when compiling a somewhat large mlir module.
Differential Revision: https://reviews.llvm.org/D89504
Commit: 7bc7d0ac7ae2e2c578463758422214e80ce5e056
https://github.com/llvm/llvm-project/commit/7bc7d0ac7ae2e2c578463758422214e80ce5e056
Author: River Riddle <riddleriver at gmail.com>
Date: 2020-10-16 (Fri, 16 Oct 2020)
Changed paths:
M mlir/include/mlir/IR/OpDefinition.h
M mlir/include/mlir/IR/SymbolInterfaces.td
M mlir/include/mlir/IR/SymbolTable.h
M mlir/lib/IR/SymbolTable.cpp
M mlir/lib/Transforms/SymbolDCE.cpp
Log Message:
-----------
[mlir] Optimize symbol related checks in SymbolDCE
This revision contains two optimizations related to symbol checking:
* Optimize SymbolOpInterface to only check for a name attribute if the operation is an optional symbol.
This removes an otherwise unnecessary attribute lookup from a majority of symbols.
* Add a new SymbolTableCollection class to represent a collection of SymbolTables.
This allows for perfoming non-flat symbol lookups in O(1) time by caching SymbolTables for symbol table operations. This class is very useful for algorithms that operate on multiple symbol tables, either recursively or not.
Differential Revision: https://reviews.llvm.org/D89505
Commit: 71eeb5ec4d6edbbef31fec83fe75933d48f101df
https://github.com/llvm/llvm-project/commit/71eeb5ec4d6edbbef31fec83fe75933d48f101df
Author: River Riddle <riddleriver at gmail.com>
Date: 2020-10-16 (Fri, 16 Oct 2020)
Changed paths:
M mlir/docs/Interfaces.md
M mlir/docs/SymbolsAndSymbolTables.md
M mlir/include/mlir/Dialect/StandardOps/IR/Ops.td
M mlir/include/mlir/IR/SymbolInterfaces.td
M mlir/include/mlir/IR/SymbolTable.h
M mlir/lib/Dialect/StandardOps/IR/Ops.cpp
M mlir/lib/IR/SymbolTable.cpp
Log Message:
-----------
[mlir] Add a new SymbolUserOpInterface class
The initial goal of this interface is to fix the current problems with verifying symbol user operations, but can extend beyond that in the future. The current problems with the verification of symbol uses are:
* Extremely inefficient:
Most current symbol users perform the symbol lookup using the slow O(N) string compare methods, which can lead to extremely long verification times in large modules.
* Invalid/break the constraints of verification pass
If the symbol reference is not-flat(and even if it is flat in some cases) a verifier for an operation is not permitted to touch the referenced operation because it may be in the process of being mutated by a different thread within the pass manager.
The new SymbolUserOpInterface exposes a method `verifySymbolUses` that will be invoked from the parent symbol table to allow for verifying the constraints of any referenced symbols. This method is passed a `SymbolTableCollection` to allow for O(1) lookups of any necessary symbol operation.
Differential Revision: https://reviews.llvm.org/D89512
Commit: a5ea60456c16faf7c75df98b03d5de5b9b6f506d
https://github.com/llvm/llvm-project/commit/a5ea60456c16faf7c75df98b03d5de5b9b6f506d
Author: River Riddle <riddleriver at gmail.com>
Date: 2020-10-16 (Fri, 16 Oct 2020)
Changed paths:
M mlir/include/mlir/Analysis/CallGraph.h
M mlir/include/mlir/Interfaces/CallInterfaces.td
M mlir/lib/Analysis/CallGraph.cpp
M mlir/lib/Interfaces/CallInterfaces.cpp
M mlir/lib/Transforms/Inliner.cpp
M mlir/lib/Transforms/SCCP.cpp
Log Message:
-----------
[mlir] Update SCCP and the Inliner to use SymbolTableCollection for symbol lookups
This transforms the symbol lookups to O(1) from O(NM), greatly speeding up both passes. For a large MLIR module this shaved seconds off of the compilation time.
Differential Revision: https://reviews.llvm.org/D89522
Compare: https://github.com/llvm/llvm-project/compare/dd4e8a54b2ba...a5ea60456c16
More information about the All-commits
mailing list