[all-commits] [llvm/llvm-project] 18465b: [mlir][NFC] Cleanup the MLIRTestReducer pass

[River Riddle via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 18465bcf4dbad4a4035f1f306b1a787e0bf92828
      https://github.com/llvm/llvm-project/commit/18465bcf4dbad4a4035f1f306b1a787e0bf92828
  Author: River Riddle <riddleriver at gmail.com>
  Date:   2021-06-23 (Wed, 23 Jun 2021)

  Changed paths:
    M mlir/test/lib/Reducer/MLIRTestReducer.cpp

  Log Message:
  -----------
  [mlir][NFC] Cleanup the MLIRTestReducer pass


  Commit: 6569cf2a44bf95106e7168bdb79c4674742708fa
      https://github.com/llvm/llvm-project/commit/6569cf2a44bf95106e7168bdb79c4674742708fa
  Author: River Riddle <riddleriver at gmail.com>
  Date:   2021-06-23 (Wed, 23 Jun 2021)

  Changed paths:
    M llvm/include/llvm/Support/ThreadPool.h
    M llvm/lib/Support/ThreadPool.cpp
    M mlir/include/mlir/IR/MLIRContext.h
    A mlir/include/mlir/IR/Threading.h
    M mlir/lib/IR/MLIRContext.cpp
    M mlir/lib/IR/Verifier.cpp
    M mlir/lib/Pass/Pass.cpp
    M mlir/lib/Transforms/Inliner.cpp
    M mlir/test/Dialect/Affine/SuperVectorize/compose_maps.mlir
    M mlir/test/Dialect/Affine/slicing-utils.mlir
    M mlir/test/IR/diagnostic-handler-filter.mlir
    M mlir/test/Pass/pass-timing.mlir
    M mlir/test/Pass/pipeline-parsing.mlir

  Log Message:
  -----------
  [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


Compare: https://github.com/llvm/llvm-project/compare/cafae0561920...6569cf2a44bf