[PATCH] D130466: [LICM] - Add option to allow data races
Shubham Narlawar via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jul 26 01:55:54 PDT 2022
gsocshubham added a comment.
In D130466#3677232 <https://reviews.llvm.org/D130466#3677232>, @efriedma wrote:
>> Or could it be in LangRef instead. Correct multi-threaded code would have used locks or atomics.
>
> The issue with this transform is that it introduces undefined behavior to code which *is* unambiguously correct. For example, say you have something like the following:
>
> int thread1counter, thread2counter;
> void f(int threadid, int *p) {
> for (int i = 0; i < 100; ++i) {
> if (p[i]) {
> if (threadid == 1)
> thread1counter++;
> else if (theadid == 2)
> thread2counter++;
> }
> }
> }
>
> You have two threads; one calls the function with threadid==1, one calls it with threadid==2. This should be fine, both intuitively and according to the standard; each thread is accessing its own data, so there's nothing to lock. But this patch makes any call to f() write to both thread1counter and thread2counter, which explodes.
The above code is a multithreaded program. This patch approach is only for single threaded programs and not for multithreaded programs.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D130466/new/
https://reviews.llvm.org/D130466
More information about the llvm-commits
mailing list