aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Transforms/Utils/InlineFunction.cpp
diff options
context:
space:
mode:
authorMatt Arsenault <Matthew.Arsenault@amd.com>2022-11-29 09:06:39 -0500
committerMatt Arsenault <Matthew.Arsenault@amd.com>2022-12-01 14:41:21 -0500
commit4ecdbf2e4ececec82cabb0d6e21f8397aa148b57 (patch)
treea59c63dc66a4b3b202a1365c85b07f56a53911e7 /llvm/lib/Transforms/Utils/InlineFunction.cpp
parentd4fbb9362071c986986a2b099c0e30aed061f53f (diff)
downloadllvm-4ecdbf2e4ececec82cabb0d6e21f8397aa148b57.zip
llvm-4ecdbf2e4ececec82cabb0d6e21f8397aa148b57.tar.gz
llvm-4ecdbf2e4ececec82cabb0d6e21f8397aa148b57.tar.bz2
llvm-reduce: Fix tsan failures
There's a data race on the UninterestingChunks set. The code seems to be operating on the assumption that all the tasks completed, so ensure the unused results do complete. This started showing up about 50% of the time when running operands-skip-parallel.ll after the recent switch to use DenseSet; previously it failed much less frequently with std::set. We should introduce a mechanism to early terminate unused results. Alternatively, I've been thinking about ways to to make the reduction order smarter. I frequently have tests that take multiple minutes to compile and hit the failure. It may be helpful to see which chunks took the least time and prefer those over just taking the first result.
Diffstat (limited to 'llvm/lib/Transforms/Utils/InlineFunction.cpp')
0 files changed, 0 insertions, 0 deletions