diff options
author | Stella Laurenzo <stellaraccident@gmail.com> | 2023-11-11 21:41:56 -0800 |
---|---|---|
committer | GitHub <noreply@github.com> | 2023-11-11 21:41:56 -0800 |
commit | 0677e54653e593ee90bb747fd75605f0bed47137 (patch) | |
tree | 5f4b0a127dc2c57691bcb0bce3f373b1ab766a1a /clang/lib/Frontend/CompilerInvocation.cpp | |
parent | 78a05b92a87cfa22263499492cc80c8c9cadcecc (diff) | |
download | llvm-0677e54653e593ee90bb747fd75605f0bed47137.zip llvm-0677e54653e593ee90bb747fd75605f0bed47137.tar.gz llvm-0677e54653e593ee90bb747fd75605f0bed47137.tar.bz2 |
[mlir][python] Allow contexts to be created with a custom thread pool. (#72042)
The existing initialization sequence always enables multi-threading at
MLIRContext construction time, making it impractical to provide a
customized thread pool.
Here, this is changed to always create the context with threading
disabled, process all site-specific init hooks (which can set thread
pools) and ultimately enable multi-threading unless if site-configured
to not do so.
This should preserve the existing user-visible initialization behavior
while also letting downstreams ensure that contexts are always created
with a shared thread pool. This was tested with IREE, which has such a
concept. Using site-specific thread tuning produced up to 2x single
compilation job behavior and customization of batch compilation (i.e. as
part of a build system) to utilize half the memory and run the entire
test suite ~2x faster. Given this, I believe that the additional
configurability can well pay for itself for implementations that use it.
We may also want to present user-level Python APIs for controlling
threading configuration in the future.
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions