[Mlir-commits] [mlir] [mlir] Use non thread-local allocator for DistinctAttr when threading is disabled (PR #128566)
Artemiy Bulavin
llvmlistbot at llvm.org
Tue Feb 25 11:19:49 PST 2025
abulavin wrote:
> I did not fully understand why there is a thread join when running with the crash reproducer. Isn't multi-threading disabled from the beginning in this case? I would have assumed the ThreadLocalCache should still work and only free the allocated attributes once the main thread terminates.
When crash reproduction is enabled, the pass manager runs its pass pipeline on a separate thread [here](https://github.com/llvm/llvm-project/blob/main/mlir/lib/Pass/PassCrashRecovery.cpp#L422-L423). This thread is created and joined outside of the MLIR context. My understanding is that disabling threading only disables the MLIR context threadpool, which has no effect on the thread in the link I provided that's used to run the pass pipeline. So the thread local cache (as intended) will allocate distinct attributes in storage local to this special 'crash recovery' thread, even when threading is disabled.
> Trying to see if I understand why it's not a problem when multi-threading is enabled: is this because we never joins thread for the lifetime of the MLIRContext?
>
> Also, you're fixing the issue for -mlir-pass-pipeline-crash-reproducer when multi-threading is disabled, but what about the combination of -mlir-pass-pipeline-crash-reproducer and multi-threading?
Ah apologies, I believe I have accidentally missed out some important information on this PR. The initial issue I was investigating involved generating **local** crash reproducers, which requires multithreading to be disabled. I need to double check what happens if multi threading is still enabled. Thanks for pointing this out.
https://github.com/llvm/llvm-project/pull/128566
More information about the Mlir-commits
mailing list