[all-commits] [llvm/llvm-project] 69c35f: [RISCV] Re-enable JIT support

Tue Aug 23 10:11:03 PDT 2022

  Branch: refs/heads/release/15.x
  Home:   https://github.com/llvm/llvm-project
  Commit: 69c35fa29af3d4695cde7654536465b760f19340
      https://github.com/llvm/llvm-project/commit/69c35fa29af3d4695cde7654536465b760f19340
  Author: Jonas Hahnfeld <hahnjo at hahnjo.de>
  Date:   2022-08-23 (Tue, 23 Aug 2022)

  Changed paths:
    M llvm/lib/Target/RISCV/TargetInfo/RISCVTargetInfo.cpp

  Log Message:
  -----------
  [RISCV] Re-enable JIT support

Commit 8922adf646 recently made JITTargetMachineBuilder honor the
hasJIT property of the target. LLVM supports just-in-time compilation
on RISC-V, so set the flag.

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

(cherry picked from commit 940733d6a0a92245912361bf116514172a15f4f8)

  Commit: 077736456fd231aa7e2555abff58b42972bfc043
      https://github.com/llvm/llvm-project/commit/077736456fd231aa7e2555abff58b42972bfc043
  Author: Alexander Shaposhnikov <ashaposhnikov at google.com>
  Date:   2022-08-23 (Tue, 23 Aug 2022)

  Changed paths:
    M llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp
    M llvm/test/Transforms/InstCombine/icmp-mul.ll

  Log Message:
  -----------
  [InstCombine] Refactor foldICmpMulConstant

This is a follow-up to 2ebfda2417
(replace "if" with "else if" since the cases nuw/nsw
were meant to be handled separately).

Test plan:
1/ ninja check-llvm check-clang check-lld
2/ Bootstrapped LLVM/Clang pass tests

(cherry picked from commit d982f1e0c69f3447c4520ae4c010520f62ed1174)

  Commit: 99b6254657797176dbe318a87450fdb56f0fdb7f
      https://github.com/llvm/llvm-project/commit/99b6254657797176dbe318a87450fdb56f0fdb7f
  Author: Kadir Cetinkaya <kadircet at google.com>
  Date:   2022-08-23 (Tue, 23 Aug 2022)

  Changed paths:
    M clang-tools-extra/clangd/ClangdLSPServer.cpp
    M clang-tools-extra/clangd/ClangdLSPServer.h
    M clang-tools-extra/clangd/ClangdServer.cpp
    M clang-tools-extra/clangd/ClangdServer.h
    M clang-tools-extra/clangd/Protocol.cpp
    M clang-tools-extra/clangd/Protocol.h
    M clang-tools-extra/clangd/XRefs.cpp
    M clang-tools-extra/clangd/XRefs.h
    M clang-tools-extra/clangd/test/initialize-params.test
    A clang-tools-extra/clangd/test/type-hierarchy-ext.test
    M clang-tools-extra/clangd/test/type-hierarchy.test
    M clang-tools-extra/clangd/unittests/TypeHierarchyTests.cpp

  Log Message:
  -----------
  [clangd] Support for standard type hierarchy

This is mostly a mechanical change to adapt standard type hierarchy
support proposed in LSP 3.17 on top of clangd's existing extension support.

This does mainly two things:
- Incorporate symbolids for all the parents inside resolution parameters, so
  that they can be retrieved from index later on. This is a new code path, as
  extension always resolved them eagerly.
- Propogate parent information when resolving children, so that at least one
  branch of parents is always preserved. This is to address a shortcoming in the
  extension.

This doesn't drop support for the extension, but it's deprecated from now on and
will be deleted in upcoming releases. Currently we use the same struct
internally but don't serialize extra fields.

Fixes https://github.com/clangd/clangd/issues/826.

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

(cherry picked from commit 83411bf06f34ae06731008eeabfc53553c1a1f86)

  Commit: bcb8d21fc35a38913b2d06c5f2c28e302c322780
      https://github.com/llvm/llvm-project/commit/bcb8d21fc35a38913b2d06c5f2c28e302c322780
  Author: Joseph Huber <jhuber6 at vols.utk.edu>
  Date:   2022-08-23 (Tue, 23 Aug 2022)

  Changed paths:
    M clang/lib/Driver/ToolChains/Cuda.cpp
    M clang/test/Driver/cuda-bindings.cu

  Log Message:
  -----------
  [CUDA] Fix output name being replaced in device-only mode

When performing device only compilation, there was an issue where
`cubin` outputs were being renamed to `cubin` despite the user's name.
This is required in a normal compilation flow as the Nvidia tools only
understand specific filenames instead of checking magic bytes for some
unknown reason. We do not want to perform this transformation when the
user is performing device only compilation.

Reviewed By: tra

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

(cherry picked from commit 3b52341116b794e53dec2fd07e568884e5a0b8bb)

  Commit: 4e4252f9b64935730702ddff3b0b51a076acbf6b
      https://github.com/llvm/llvm-project/commit/4e4252f9b64935730702ddff3b0b51a076acbf6b
  Author: Nemanja Ivanovic <nemanjai at ca.ibm.com>
  Date:   2022-08-23 (Tue, 23 Aug 2022)

  Changed paths:
    M llvm/utils/unittest/CMakeLists.txt

  Log Message:
  -----------
  [GTest] Change detection of libpthread

We currently use CMake's find_library function to detect whether
libpthread exists on the system to determine if pthread should
be added on the link step. However, there are configurations in
which CMake's path checking fails to find the library even though
the toolchain has it.

One such case is with Clang 14.0.0 on PowerPC. Due to a recent
change, the build puts libc++ and related libraries in a
subdirectory that appears to depend on the default target triple.
CMake then uses that subdirectory to determine the architecture
and adds that name to its search paths. However, the triple for
the system GNU toolchain is different so CMake fails to find it.
Namely, Clang 14.0.0's default target triple and the subdirectory
name is powerpc64le-unknown-linux-gnu whereas the system GNU
toolchain has powerpc64le-linux-gnu. Clang's driver has no trouble
finding either the GNU includes/libraries or Clang's own. But
CMake seems to get this wrong.

The net result of this is that we can't do a shared libraries
build of ToT with Clang 14.0.0.

This patch proposes using HAVE_LIBPTHREAD which CMake seems to
determine by compiling a test file with -lpthread (or perhaps
-pthread, I can't really get CMake to tell me how it is figuring
this out). If that variable tells CMake that the build compiler
accepts the pthread option, it seems reasonable to depend on
that variable to determine if we should add it to the link step
when building the llvm_gtest library.

(cherry picked from commit 8537a99b2c1d08e9e586b3fb9e36728075ec4a03)

Compare: https://github.com/llvm/llvm-project/compare/b11009ffe7b6...4e4252f9b649