[all-commits] [llvm/llvm-project] 4683a4: Fix assert during the call to getCanonicalDecl.

Vladimir Plyashkun via All-commits all-commits at lists.llvm.org
Mon Aug 15 00:32:35 PDT 2022


  Branch: refs/heads/release/15.x
  Home:   https://github.com/llvm/llvm-project
  Commit: 4683a4561c2513ae7384aa9fd752f45a72eecc83
      https://github.com/llvm/llvm-project/commit/4683a4561c2513ae7384aa9fd752f45a72eecc83
  Author: Jennifer Yu <jennifer.yu at intel.com>
  Date:   2022-08-15 (Mon, 15 Aug 2022)

  Changed paths:
    M clang/lib/Sema/SemaOpenMP.cpp
    M clang/test/OpenMP/parallel_default_messages.cpp

  Log Message:
  -----------
  Fix assert during the call to getCanonicalDecl.
https://github.com/llvm/llvm-project/issues/56884

The root problem is in isOpenMPRebuildMemberExpr, it is only need to rebuild
for field expression.  No need for member function call.

The fix is to check field for member expression and skip rebuild for member
function call.

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

(cherry picked from commit a7bca18bc50cd2483fded0c77706980b2721ce6a)


  Commit: 2c3f5d71e3118d67ccd0c988bcc1f9bc0710574c
      https://github.com/llvm/llvm-project/commit/2c3f5d71e3118d67ccd0c988bcc1f9bc0710574c
  Author: David Truby <david.truby at arm.com>
  Date:   2022-08-15 (Mon, 15 Aug 2022)

  Changed paths:
    M clang/lib/Sema/SemaExpr.cpp
    M clang/test/CodeGen/aarch64-sve-vector-arith-ops.c
    M clang/test/Sema/sizeless-1.c
    M clang/test/SemaCXX/sizeless-1.cpp

  Log Message:
  -----------
  [clang][AArch64][SVE] Add unary +/- operators for SVE types

This patch enables the unary promotion and negation operators on
SVE types.

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

(cherry picked from commit 286d59ef6f7118c8a0600f3d281593700528a5d3)


  Commit: 5c6590eb2775a545ad37c38c1c1f440e5687b079
      https://github.com/llvm/llvm-project/commit/5c6590eb2775a545ad37c38c1c1f440e5687b079
  Author: David Truby <david.truby at arm.com>
  Date:   2022-08-15 (Mon, 15 Aug 2022)

  Changed paths:
    M clang/docs/LanguageExtensions.rst

  Log Message:
  -----------
  [clang] Correct documentation for NEON and SVE operator support

Previously the language extension documentation didn't mention SVE and
was incomplete in listing the C/C++ operators supported on NEON. This
corrects the documentation to be in line with the implementation.

(cherry picked from commit e4642d78a89930720bc84a4775614c45327bc0dc)


  Commit: aa20ed6187b7300ef627ff4c28d8150c41cafb54
      https://github.com/llvm/llvm-project/commit/aa20ed6187b7300ef627ff4c28d8150c41cafb54
  Author: David Truby <david.truby at arm.com>
  Date:   2022-08-15 (Mon, 15 Aug 2022)

  Changed paths:
    M clang/docs/LanguageExtensions.rst

  Log Message:
  -----------
  [clang][AArch64][SVE] Clarify documentation for sizeof operator on SVE

Previously the table in LanguageExtensions said that sizeof worked on
SVE types but this is only correct for fixed-length vectors so a
clarification has been added.

(cherry picked from commit bbb30bd54a6447702f9f59a2ae4c478eb7133ae0)


  Commit: 5932bf1730629a1c2673cfdd31d5d823e62a33c3
      https://github.com/llvm/llvm-project/commit/5932bf1730629a1c2673cfdd31d5d823e62a33c3
  Author: David Truby <david.truby at arm.com>
  Date:   2022-08-15 (Mon, 15 Aug 2022)

  Changed paths:
    M clang/lib/Basic/Targets/AArch64.cpp
    M clang/test/Preprocessor/aarch64-target-features.c

  Log Message:
  -----------
  [clang][AArch64][SVE] Change SVE_VECTOR_OPERATORS macro for VLA vectors

The __ARM_FEATURE_SVE_VECTOR_OPERATORS macro should be changed to
indicate that this feature is now supported on VLA vectors as well as
VLS vectors. There is a complementary PR to the ACLE spec here
https://github.com/ARM-software/acle/pull/213

Reviewed By: peterwaller-arm

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

(cherry picked from commit 13a784f368ef062a7bd652829bcf8bbdd94dc659)


  Commit: a9ac5ac72816978bcf1a9d11def8e57dee25d330
      https://github.com/llvm/llvm-project/commit/a9ac5ac72816978bcf1a9d11def8e57dee25d330
  Author: Shilei Tian <i at tianshilei.me>
  Date:   2022-08-15 (Mon, 15 Aug 2022)

  Changed paths:
    M clang/lib/CodeGen/CGStmtOpenMP.cpp
    M clang/lib/CodeGen/CodeGenFunction.h
    A clang/test/OpenMP/bug56913.c
    M clang/test/OpenMP/for_linear_codegen.cpp
    M clang/test/OpenMP/parallel_master_taskloop_simd_lastprivate_codegen.cpp

  Log Message:
  -----------
  [Clang][OpenMP] Fix the issue that `llvm.lifetime.end` is emitted too early for variables captured in linear clause

Currently if an OpenMP program uses `linear` clause, and is compiled with
optimization, `llvm.lifetime.end` for variables listed in `linear` clause are
emitted too early such that there could still be uses after that. Let's take the
following code as example:
```
// loop.c
int j;
int *u;

void loop(int n) {
  int i;
  for (i = 0; i < n; ++i) {
    ++j;
    u = &j;
  }
}
```
We compile using the command:
```
clang -cc1 -fopenmp-simd -O3 -x c -triple x86_64-apple-darwin10 -emit-llvm loop.c -o loop.ll
```
The following IR (simplified) will be generated:
```
@j = local_unnamed_addr global i32 0, align 4
@u = local_unnamed_addr global ptr null, align 8

define void @loop(i32 noundef %n) local_unnamed_addr {
entry:
  %j = alloca i32, align 4
  %cmp = icmp sgt i32 %n, 0
  br i1 %cmp, label %simd.if.then, label %simd.if.end

simd.if.then:                                     ; preds = %entry
  call void @llvm.lifetime.start.p0(i64 4, ptr nonnull %j)
  store ptr %j, ptr @u, align 8
  call void @llvm.lifetime.end.p0(i64 4, ptr nonnull %j)
  %0 = load i32, ptr %j, align 4
  store i32 %0, ptr @j, align 4
  br label %simd.if.end

simd.if.end:                                      ; preds = %simd.if.then, %entry
  ret void
}
```
The most important part is:
```
  call void @llvm.lifetime.end.p0(i64 4, ptr nonnull %j)
  %0 = load i32, ptr %j, align 4
  store i32 %0, ptr @j, align 4
```
`%j` is still loaded after `@llvm.lifetime.end.p0(i64 4, ptr nonnull %j)`. This
could cause the backend incorrectly optimizes the code and further generates
incorrect code. The root cause is, when we emit a construct that could have
`linear` clause, it usually has the following pattern:
```
EmitOMPLinearClauseInit(S)
{
  OMPPrivateScope LoopScope(*this);
  ...
  EmitOMPLinearClause(S, LoopScope);
  ...
  (void)LoopScope.Privatize();
  ...
}
EmitOMPLinearClauseFinal(S, [](CodeGenFunction &) { return nullptr; });
```
Variables that need to be privatized are added into `LoopScope`, which also
serves as a RAII object. When `LoopScope` is destructed and if optimization is
enabled, a `@llvm.lifetime.end` is also emitted for each privatized variable.
However, the writing back to original variables in `linear` clause happens after
the scope in `EmitOMPLinearClauseFinal`, causing the issue we see above.

A quick "fix" seems to be, moving `EmitOMPLinearClauseFinal` inside the scope.
However, it doesn't work. That's because the local variable map has been updated
by `LoopScope` such that a variable declaration is mapped to the privatized
variable, instead of the actual one. In that way, the following code will be
generated:
```
  %0 = load i32, ptr %j, align 4
  store i32 %0, ptr %j, align 4
  call void @llvm.lifetime.end.p0(i64 4, ptr nonnull %j)
```
Well, now the life time is correct, but apparently the writing back is broken.

In this patch, a new function `OMPPrivateScope::restoreMap` is added and called
before calling `EmitOMPLinearClauseFinal`. This can make sure that
`EmitOMPLinearClauseFinal` can find the orignal varaibls to write back.

Fixes #56913.

Reviewed By: ABataev

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

(cherry picked from commit e21202dac18ed7f718d26a0e131f96b399b4891c)


  Commit: 6ce43697482ea0c841f0cf614fcda09ceeb325a9
      https://github.com/llvm/llvm-project/commit/6ce43697482ea0c841f0cf614fcda09ceeb325a9
  Author: Johannes Doerfert <johannes at jdoerfert.de>
  Date:   2022-08-15 (Mon, 15 Aug 2022)

  Changed paths:
    M openmp/libomptarget/DeviceRTL/src/Kernel.cpp

  Log Message:
  -----------
  [OpenMP][FIX] Ensure __kmpc_kernel_parallel is reachable

The problem is we create the call to __kmpc_kernel_parallel in the
openmp-opt pass but while we optimize the code, the call is not there
yet. Thus, we assume we never reach it from __kmpc_target_deinit. That
allows us to remove the store in there (`ParallelRegionFn = nullptr`),
which leads to bad results later on.

This is a shortstop solution until we come up with something better.

Fixes https://github.com/llvm/llvm-project/issues/57064

(cherry picked from commit a8cda3290944687b4fd0138e63cd980ea497a438)


  Commit: ab09289dbf1d08db83e16314cf425d25c0138e66
      https://github.com/llvm/llvm-project/commit/ab09289dbf1d08db83e16314cf425d25c0138e66
  Author: Amy Kwan <amy.kwan1 at ibm.com>
  Date:   2022-08-15 (Mon, 15 Aug 2022)

  Changed paths:
    M libcxx/test/libcxx/strings/basic.string/string.capacity/max_size.pass.cpp

  Log Message:
  -----------
  [libcxx] [test] Fix max_size.pass.cpp for PowerPC targets

This patch fixes the max_size.pass.cpp test for PowerPC targets, depending on
endianness.

We will exhibit the full_size() behaviour for little endian
(where __endian_factor = 2 ), and the half_size() behaviour for
big endian (where __endian_factor = 1).

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

(cherry picked from commit e2e9e2ce8efd12f0f2b7a12be113d4241706ddf2)


  Commit: 76522bf130996b9abe0029310d41e491832bced3
      https://github.com/llvm/llvm-project/commit/76522bf130996b9abe0029310d41e491832bced3
  Author: Simon Pilgrim <llvm-dev at redking.me.uk>
  Date:   2022-08-15 (Mon, 15 Aug 2022)

  Changed paths:
    M clang/test/Preprocessor/predefined-arch-macros.c

  Log Message:
  -----------
  [clang][X86] Add RDPRU predefined macro tests for znver2/znver3 targets

These were missed in D128934

(cherry picked from commit 6e19e6ce36e44554ac9fbf8b2780de05e922c849)


  Commit: 804e4538577fe667454285c88f212abfe58516d5
      https://github.com/llvm/llvm-project/commit/804e4538577fe667454285c88f212abfe58516d5
  Author: Simon Pilgrim <llvm-dev at redking.me.uk>
  Date:   2022-08-15 (Mon, 15 Aug 2022)

  Changed paths:
    M clang/lib/Headers/cpuid.h
    M llvm/lib/Support/Host.cpp

  Log Message:
  -----------
  [X86] Add RDPRU instruction CPUID bit masks

As mentioned on D128934 - we weren't including the CPUID bit handling for the RDPRU instruction

AMD's APMv3 (24594) lists it as CPUID Fn8000_0008_EBX Bit#4

(cherry picked from commit 08a880509e4f7ca8d346dce42fe7528c3a33f22c)


  Commit: 9c4cab01e51e17635dfa5dff31c893980f701796
      https://github.com/llvm/llvm-project/commit/9c4cab01e51e17635dfa5dff31c893980f701796
  Author: Vladimir Plyashkun <vladimir.plyashkun at jetbrains.com>
  Date:   2022-08-15 (Mon, 15 Aug 2022)

  Changed paths:
    M clang-tools-extra/docs/clang-tidy/checks/abseil/no-internal-dependencies.rst

  Log Message:
  -----------
  [clang-tidy][docs] Fixed page title for abseil-no-internal-dependencies check documentation

It seems that documentation for abseil-no-internal-dependencies has invalid title.
This can be checked by looking at the actual web-site - https://clang.llvm.org/extra/clang-tidy/checks/abseil/no-internal-dependencies.html
There is redundant "subl.. title:: clang-tidy - abseil-no-internal-dependencies" paragraph in the beginning.

Reviewed By: njames93, sylvestre.ledru

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

(cherry picked from commit 6c7b049f6eb78edf83506a858c7b211a7c70afd8)


Compare: https://github.com/llvm/llvm-project/compare/fbd2950d8d0d...9c4cab01e51e


More information about the All-commits mailing list