[all-commits] [llvm/llvm-project] 272bc2: [LoopReroll] Fix rerolling loop with use outside t...

[KAWASHIMA Takahiro via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 272bc25bc1401d5dc1407ad22a3172ee6914d007
      https://github.com/llvm/llvm-project/commit/272bc25bc1401d5dc1407ad22a3172ee6914d007
  Author: KAWASHIMA Takahiro <t-kawashima at fujitsu.com>
  Date:   2020-05-13 (Wed, 13 May 2020)

  Changed paths:
    M llvm/lib/Transforms/Scalar/LoopRerollPass.cpp
    A llvm/test/Transforms/LoopReroll/external_use.ll

  Log Message:
  -----------
  [LoopReroll] Fix rerolling loop with use outside the loop

Fixes PR41696

The loop-reroll pass generates an invalid IR (or its assertion
fails in debug build) if values of the base instruction and
other root instructions (terms used in the loop-reroll pass)
are used outside the loop block. See IRs written in PR41696
as examples.

The current implementation of the loop-reroll pass can reroll
only loops that don't have values that are used outside the
loop, except reduced values (the last values of reduction chains).
This is described in the comment of the `LoopReroll::reroll`
function.
https://github.com/llvm/llvm-project/blob/llvmorg-10.0.0/llvm/lib/Transforms/Scalar/LoopRerollPass.cpp#L1600

This is checked in the `LoopReroll::DAGRootTracker::validate`
function.
https://github.com/llvm/llvm-project/blob/llvmorg-10.0.0/llvm/lib/Transforms/Scalar/LoopRerollPass.cpp#L1393

However, the base instruction and other root instructions skip
this check in the validation loop.
https://github.com/llvm/llvm-project/blob/llvmorg-10.0.0/llvm/lib/Transforms/Scalar/LoopRerollPass.cpp#L1229

Moving the check in front of the skip is the logically simplest
fix. However, inserting the check in an earlier stage is better
in terms of compilation time of unrerollable loops. This fix
inserts the check for the base instruction into the function
to validate possible base/root instructions. Check for other
root instructions is unnecessary because they don't match any
base instructions if they have uses outside the loop.

Differential Revision: https://reviews.llvm.org/D79549


  Commit: 7d4167430c411ba1441260be9243d3401695ea7a
      https://github.com/llvm/llvm-project/commit/7d4167430c411ba1441260be9243d3401695ea7a
  Author: KAWASHIMA Takahiro <t-kawashima at fujitsu.com>
  Date:   2020-05-13 (Wed, 13 May 2020)

  Changed paths:
    M compiler-rt/lib/profile/GCDAProfiling.c
    M compiler-rt/test/profile/Posix/instrprof-gcov-parallel.test

  Log Message:
  -----------
  [gcov] Fix simultaneous .gcda creation/lock

Fixes PR45673

The commit 9180c14fe4d (D76206) resolved only a part of the problem
of concurrent .gcda file creation. It ensured that only one process
creates the file but did not ensure that the process locks the
file first. If not, the process which created the file may clobber
the contents written by a process which locked the file first.
This is the cause of PR45673.

This commit prevents the clobbering by revising the assumption
that a process which creates the file locks the file first.
Regardless of file creation, a process which locked the file first
uses fwrite (new_file==1) and other processes use mmap (new_file==0).

I also tried to keep the creation/first-lock process same by using
mkstemp/link/unlink but the code gets long. This commit is more
simple.

Note: You may be confused with other changes which try to resolve
concurrent file access. My understanding is (may not be correct):

D76206:   Resolve race of .gcda file creation (but not lock)
This one: Resolve race of .gcda file creation and lock
D54599:   Same as D76206 but abandoned?
D70910:   Resolve race of multi-threaded counter flushing
D74953:   Resolve counter sharing between parent/children processes
D78477:   Revision of D74953

Differential Revision: https://reviews.llvm.org/D79556


Compare: https://github.com/llvm/llvm-project/compare/67087a7b7659...7d4167430c41