[PATCH] D130466: [LICM] - Add option to allow data races

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

> 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.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130466/new/

https://reviews.llvm.org/D130466