River Riddle deae9b5f50 [mlir] Add a ThreadPool to MLIRContext and refactor MLIR threading usage ... This revision refactors the usage of multithreaded utilities in MLIR to use a common thread pool within the MLIR context, in addition to a new utility that makes writing multi-threaded code in MLIR less error prone. Using a unified thread pool brings about several advantages: * Better thread usage and more control We currently use the static llvm threading utilities, which do not allow multiple levels of asynchronous scheduling (even if there are open threads). This is due to how the current TaskGroup structure works, which only allows one truly multithreaded instance at a time. By having our own ThreadPool we gain more control and flexibility over our job/thread scheduling, and in a followup can enable threading more parts of the compiler. * The static nature of TaskGroup causes issues in certain configurations Due to the static nature of TaskGroup, there have been quite a few problems related to destruction that have caused several downstream projects to disable threading. See D104207 for discussion on some related fallout. By having a ThreadPool scoped to the context, we don't have to worry about destruction and can ensure that any additional MLIR thread usage ends when the context is destroyed. Differential Revision: https://reviews.llvm.org/D104516		2021-06-23 01:29:24 +00:00
..
llvm	[mlir] Add a ThreadPool to MLIRContext and refactor MLIR threading usage	2021-06-23 01:29:24 +00:00
llvm-c	[ORC][C-bindings] Add access to LLJIT IRTransformLayer, ThreadSafeModule utils.	2021-06-19 11:50:27 +10:00