[all-commits] [llvm/llvm-project] 01e3eb: [OpenMP][Offloading] Fix infinite loop in applyToS...

Tue Feb 15 03:03:15 PST 2022

  Branch: refs/heads/release/14.x
  Home:   https://github.com/llvm/llvm-project
  Commit: 01e3eb2bd438089ced550ab74de497f2bfa67038
      https://github.com/llvm/llvm-project/commit/01e3eb2bd438089ced550ab74de497f2bfa67038
  Author: Shilei Tian <i at tianshilei.me>
  Date:   2022-02-15 (Tue, 15 Feb 2022)

  Changed paths:
    M openmp/libomptarget/src/omptarget.cpp
    A openmp/libomptarget/test/offloading/bug53727.cpp

  Log Message:
  -----------
  [OpenMP][Offloading] Fix infinite loop in applyToShadowMapEntries

This patch fixes the issue that the for loop in `applyToShadowMapEntries`
is infinite because `Itr` is not incremented in `CB`. Fixes #53727.

Reviewed By: jdoerfert

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

(cherry picked from commit c27f530d4c6306b2010306131f66e771d6a66594)

  Commit: af19ae529271f9ae96927662d7d876489115fb26
      https://github.com/llvm/llvm-project/commit/af19ae529271f9ae96927662d7d876489115fb26
  Author: David Spickett <david.spickett at linaro.org>
  Date:   2022-02-15 (Tue, 15 Feb 2022)

  Changed paths:
    M lldb/include/lldb/Target/Process.h
    M lldb/source/Commands/CommandObjectMemory.cpp
    M lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
    M lldb/source/Plugins/Process/Windows/Common/ProcessWindows.h
    M lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
    M lldb/source/Plugins/Process/elf-core/ProcessElfCore.h
    M lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
    M lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
    M lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
    M lldb/source/Plugins/Process/mach-core/ProcessMachCore.h
    M lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp
    M lldb/source/Plugins/Process/minidump/ProcessMinidump.h
    M lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp
    M lldb/source/Plugins/Process/scripted/ScriptedProcess.h
    M lldb/source/Target/Process.cpp
    A lldb/test/API/linux/aarch64/tagged_memory_region/Makefile
    A lldb/test/API/linux/aarch64/tagged_memory_region/TestAArch64LinuxTaggedMemoryRegion.py
    A lldb/test/API/linux/aarch64/tagged_memory_region/main.c
    M llvm/docs/ReleaseNotes.rst

  Log Message:
  -----------
  Reland "[lldb] Remove non address bits when looking up memory regions"

(cherry picked from 2937b282188bafb6bdb65ee87c70e9109aa910b7)

This reverts commit 0df522969a7a0128052bd79182c8d58e00556e2f.

Additional checks are added to fix the detection of the last memory region
in GetMemoryRegions or repeating the "memory region" command when the
target has non-address bits.

Normally you keep reading from address 0, looking up each region's end
address until you get LLDB_INVALID_ADDR as the region end address.
(0xffffffffffffffff)

This is what the remote will return once you go beyond the last mapped region:
[0x0000fffffffdf000-0x0001000000000000) rw- [stack]
[0x0001000000000000-0xffffffffffffffff) ---

Problem is that when we "fix" the lookup address, we remove some bits
from it. On an AArch64 system we have 48 bit virtual addresses, so when
we fix the end address of the [stack] region the result is 0.
So we loop back to the start.

[0x0000fffffffdf000-0x0001000000000000) rw- [stack]
[0x0000000000000000-0x0000000000400000) ---

To fix this I added an additional check for the last range.
If the end address of the region is different once you apply
FixDataAddress, we are at the last region.

Since the end of the last region will be the last valid mappable
address, plus 1. That 1 will be removed by the ABI plugin.

The only side effect is that on systems with non-address bits, you
won't get that last catch all unmapped region from the max virtual
address up to 0xf...f.

[0x0000fffff8000000-0x0000fffffffdf000) ---
[0x0000fffffffdf000-0x0001000000000000) rw- [stack]
<ends here>

Though in some way this is more correct because that region is not
just unmapped, it's not mappable at all.

No extra testing is needed because this is already covered by
TestMemoryRegion.py, I simply forgot to run it on system that had
both top byte ignore and pointer authentication.

This change has been tested on a qemu VM with top byte ignore,
memory tagging and pointer authentication enabled.

Reviewed By: omjavaid

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

  Commit: 78f8449e01f7a397c6ba1cb7e9d0e1e863bbeaa5
      https://github.com/llvm/llvm-project/commit/78f8449e01f7a397c6ba1cb7e9d0e1e863bbeaa5
  Author: Jonathan Peyton <jonathan.l.peyton at intel.com>
  Date:   2022-02-15 (Tue, 15 Feb 2022)

  Changed paths:
    M openmp/runtime/src/kmp_affinity.cpp

  Log Message:
  -----------
  [OpenMP][libomp] Replace accidental VLA with KMP_ALLOCA

MSVC does not support variable length arrays. Replace with KMP_ALLOCA
which is already used in the same file for stack-allocated variables.

(cherry picked from commit 6be7c21b57e4a45b012209974ab9038b679134f5)

  Commit: 8f8a31ec88b5908870960061dcc24007e7682925
      https://github.com/llvm/llvm-project/commit/8f8a31ec88b5908870960061dcc24007e7682925
  Author: Craig Topper <craig.topper at sifive.com>
  Date:   2022-02-15 (Tue, 15 Feb 2022)

  Changed paths:
    M llvm/test/CodeGen/RISCV/rvv/vsetvli-insert-crossbb.mir

  Log Message:
  -----------
  [RISCV] Add test case for a vsetvli insertion bug found after D118667.

We're missing a vsetvli before a vse after a redsum in this test.

This appears to be because the vmv.s.x has a VL of 1, but did not
trigger a vsetvli because it is a scalar move op and any non-zero
VL would work. So it looked at it the predecessors and decided it was
that they all had a non-zero vl. Then the redsum was visited, it
also took the VL from the predecessors since the vmv.s.x and the 4
was found compatible.

Finally we visit the vse and it looks at the BBLocalInfo and sees
that is compatible because it contains a VL of 1 from the vmv.s.x,
the first instruction in the block. BBLocalInfo was not updated
when the vredsum was visited because BBLocalInfo was valid and no
vsetvli was generated.

I think fundamentally the vmv.s.x optimization has the same first
phase and third phase not matching problem that D118667 was trying
to fix for stores.

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

(cherry picked from commit ba9a7ae798053d7cf741143739351b5a4ac29d8b)

  Commit: e22573ab7b2ddd24699f5e645562cf50f0858e33
      https://github.com/llvm/llvm-project/commit/e22573ab7b2ddd24699f5e645562cf50f0858e33
  Author: Craig Topper <craig.topper at sifive.com>
  Date:   2022-02-15 (Tue, 15 Feb 2022)

  Changed paths:
    M llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
    M llvm/test/CodeGen/RISCV/rvv/vsetvli-insert-crossbb.mir

  Log Message:
  -----------
  Revert "[RISCV] Fix a vsetvli insertion bug involving loads/stores." and "[RISCC] Add missing words to comment. NFC"

This reverts commit f943c58cae2480755cecdac5be832274f238df93.
and commit 7eb781072744b31a60e82b5a5903471032d4845f.

This introduced a new bug that appears to be easier to hit.

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

(cherry picked from commit f35ac872b8224f771808a9ecd5c4da0fe307ac9c)

  Commit: 3b544440f63157411d2bcf0e195329f7560a6991
      https://github.com/llvm/llvm-project/commit/3b544440f63157411d2bcf0e195329f7560a6991
  Author: Craig Topper <craig.topper at sifive.com>
  Date:   2022-02-15 (Tue, 15 Feb 2022)

  Changed paths:
    M llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
    M llvm/test/CodeGen/RISCV/rvv/vsetvli-insert-crossbb.mir

  Log Message:
  -----------
  [RISCV] Insert VSETVLI at the end of a basic block if we didn't produce BlockInfo.Exit.

This is an alternative to D118667 that instead of fixing the store
to match phase 1, it tries to detect the mismatch with the expected
value at the end of the block. This inserts a vsetvli after the vse
to satisfy the requirement of the other basic block.

We still have serious design issues in the pass, that is going to
require some rethinking.

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

(cherry picked from commit 541c9ba842256023611e5a6c5f01e01c40688044)

  Commit: 89fb25f481a5c829498c408bad54c8640ccc6233
      https://github.com/llvm/llvm-project/commit/89fb25f481a5c829498c408bad54c8640ccc6233
  Author: Michał Górny <mgorny at moritz.systems>
  Date:   2022-02-15 (Tue, 15 Feb 2022)

  Changed paths:
    M lldb/source/Commands/CommandObjectThread.cpp
    A lldb/test/Shell/Commands/Inputs/sigchld.c
    A lldb/test/Shell/Commands/command-thread-siginfo.test

  Log Message:
  -----------
  [lldb] [Commands] Implement "thread siginfo"

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

(cherry picked from commit 287ce6b51675aee43870bebfff68bb144d1ab90e)

Compare: https://github.com/llvm/llvm-project/compare/f0b442c8ac58...89fb25f481a5