| Issue |
53056
|
| Summary |
`MlirOpMain` creates threads when `--mlir-disable-threading` is specified
|
| Labels |
mlir:core
|
| Assignees |
|
| Reporter |
teqdruid
|
This is a minor issue, since it only affects testing drivers which use the `MlirOpMain` and has no functional effect.
When `*-opt` is invoked with `--mlir-disable-threading`, multiple threads are spun up and then (presumably) not used. The problem is here: https://github.com/llvm/llvm-project/blob/7607ddd981dd15a8298e6834a66125f4a389b607/mlir/lib/Support/MlirOptMain.cpp#L147
The threads are created in the `ThreadPool` constructor, so `ThreadPool` should only be constructed if threads will actually be used. The problem is that `MlirOptMain` doesn't know if `--mlir-disable-threading` has been specified since that `llvm::cl::opt` is in `MLIRContext.cpp` and `isThreadingGloballyDisabled()` is a private function. It seems like if `MlirOptMain` used the threading flag in `MLIRContext` it would result in the desired behavior:
https://github.com/llvm/llvm-project/blob/7607ddd981dd15a8298e6834a66125f4a389b607/mlir/lib/IR/MLIRContext.cpp#L238
Why does `MlirOptMain` explicitly use its own `ThreadPool`? It doesn't appear to use `threadPool` after passing it off to the context.
For reference, my only interest here is that GDB is significantly slower in the presence of threads. I think I can work around this issue by compiling without threading, but that's not ideal.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
