[all-commits] [llvm/llvm-project] c6d641: [compiler-rt] Use .globl for FreeBSD/NetBSD interc...
Serge Pavlov via All-commits
all-commits at lists.llvm.org
Fri Aug 25 00:37:14 PDT 2023
Branch: refs/heads/release/17.x
Home: https://github.com/llvm/llvm-project
Commit: c6d6417a0b7cd3a855ae8dcc6dd1111e1759dd2a
https://github.com/llvm/llvm-project/commit/c6d6417a0b7cd3a855ae8dcc6dd1111e1759dd2a
Author: Jessica Clarke <jrtc27 at jrtc27.com>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
M compiler-rt/lib/interception/interception.h
Log Message:
-----------
[compiler-rt] Use .globl for FreeBSD/NetBSD interceptor wrappers
On FreeBSD and NetBSD we don't use .weak due to differing semantics.
Currently we end up using no directive, which gives a local symbol,
whereas the closer thing to a weak symbol would be a global one. In
particular, both GNU and LLVM toolchains cannot handle a GOT-indirect
reference to a local symbol at a non-zero offset within a section on
AArch64 (see https://github.com/ARM-software/abi-aa/issues/217), and so
interceptors do not work on FreeBSD/arm64, failing to link with LLD.
Switching to .globl both works around this bug and more closely aligns
such non-weak platforms with weak ones.
Fixes https://github.com/llvm/llvm-project/issues/63418
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D158552
(cherry picked from commit 7e1afab1b1821550c5f8d0d6a50636236fa02e2c)
Commit: 2e17e9e261dd511398a399226ce9e69f3dbc5d3f
https://github.com/llvm/llvm-project/commit/2e17e9e261dd511398a399226ce9e69f3dbc5d3f
Author: Craig Topper <craig.topper at sifive.com>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
M clang/lib/AST/ASTContext.cpp
M clang/test/Sema/riscv-rvv-lax-vector-conversions.c
Log Message:
-----------
[RISCV] Check type size for lax conversions between RVV builtin types and VectorType::RVVFixedLengthDataVector.
This code was copied from SVE and modified for RVV. For SVE, there
is only one size for builtin types so they didn't need to check
the size. For RVV, due to LMUL there are 7 different sizes of builtin
types so we do need to check the size.
I'm not sure we should have lax vector conversions at all for RVV.
That appears to be contributing to https://github.com/llvm/llvm-project/issues/64404
This patch at least fixes the obvious correctness issue.
This should be backported to LLVM 17.
Reviewed By: jacquesguan
Differential Revision: https://reviews.llvm.org/D157130
(cherry picked from commit 33af2f131db71a18aefc5469129540e2097a537f)
Commit: 4d5feafb9dc0d7e9b12b116f07307085687c2e3d
https://github.com/llvm/llvm-project/commit/4d5feafb9dc0d7e9b12b116f07307085687c2e3d
Author: Michael Halkenhaeuser <MichaelGerald.Halkenhauser at amd.com>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
M openmp/libomptarget/src/OmptCallback.cpp
M openmp/libomptarget/src/OmptInterface.h
M openmp/libomptarget/src/device.cpp
M openmp/libomptarget/test/ompt/veccopy_disallow_both.c
M openmp/libomptarget/test/ompt/veccopy_emi.c
M openmp/libomptarget/test/ompt/veccopy_emi_map.c
Log Message:
-----------
[OpenMP][OMPT] Fix reported target pointer for data alloc callback
This patch fixes: https://github.com/llvm/llvm-project/issues/64671
DataOp EMI callbacks would not report the correct target pointer.
This is now alleviated by passing a `void**` into the function which
emits the actual callback, then evaluating that pointer.
Note: Since this is only done after the pointer has been properly
updated, only `endpoint=2` callbacks will show a non-null value.
Reviewed By: dhruvachak, jdoerfert
Differential Revision: https://reviews.llvm.org/D157996
(cherry picked from commit 41f3626f8b300cef24c06d9e8b7cf53029a4330a)
Commit: 1d54dc2f75861295aeb99f480aed244dc5cedea5
https://github.com/llvm/llvm-project/commit/1d54dc2f75861295aeb99f480aed244dc5cedea5
Author: Michael Halkenhaeuser <MichaelGerald.Halkenhauser at amd.com>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
M openmp/libomptarget/src/interface.cpp
A openmp/libomptarget/test/ompt/veccopy_data.c
Log Message:
-----------
[OpenMP][OMPT] Fix `target enter data` callback ordering & reported device num
This patch fixes: https://github.com/llvm/llvm-project/issues/64738
We observed multiple issues, primarily that the `DeviceId` was reported as -1
in certain scenarios. The reason for this is simply that the device is not
initialized at that point. Hence, we need to move the RAII object creation just
after the `checkDeviceAndCtors`, closer to the actual call we want to observe.
This also solves an odering issue where one `target enter data` callback would
be executed before the `Init` callback.
Additionally, this change will also fix that the callbacks corresponding to
`enter / exit data` and `update` in conjunction with `nowait` would not result
in the emission of an OMPT callback.
Added a testcase to cover initialized device number and `omp target` constructs.
Reviewed By: dhruvachak
Differential Revision: https://reviews.llvm.org/D157605
(cherry picked from commit 57f0bdc8fb1e66d4ed9cfb57f1ef699eefd99646)
Commit: 6d0ff3d27ced294d89775fda9ff4de2c6844d9e0
https://github.com/llvm/llvm-project/commit/6d0ff3d27ced294d89775fda9ff4de2c6844d9e0
Author: eopXD <yueh.ting.chen at gmail.com>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
M clang/lib/CodeGen/CGCall.cpp
M clang/test/CodeGen/RISCV/rvv-intrinsics-handcrafted/rvv-tuple-type.c
M llvm/test/Transforms/SROA/scalable-vector-struct.ll
Log Message:
-----------
[CGCall][RISCV] Handle function calls with parameter of RVV tuple type
This was an oversight in D146872, where function calls with tuple type
was not covered. This commit fixes this.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D157953
(cherry picked from commit 39a41c8905618fc942100630b4ea37f0cb95e786)
Commit: 7dbb49af2aba685d8776730fb362448a963a2aa5
https://github.com/llvm/llvm-project/commit/7dbb49af2aba685d8776730fb362448a963a2aa5
Author: Chuanqi Xu <yedeng.yd at linux.alibaba.com>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
M clang/test/CodeGenCoroutines/coro-halo.cpp
A clang/test/CodeGenCoroutines/pr59723.cpp
M llvm/lib/Transforms/Coroutines/CoroElide.cpp
Log Message:
-----------
[Coroutines] [CoroElide] Don't think exceptional terminator don't leak coro handle unconditionally any more
Close https://github.com/llvm/llvm-project/issues/59723.
The fundamental cause of the above issue is that we assumed the memory
of coroutine frame can be released by stack unwinding automatically
if the allocation of the coroutine frame is elided. But we missed one
point: the stack unwinding has different semantics with the explicit
coroutine_handle<>::destroy(). Since the latter is explicit so it shows
the intention of the user. So we can blame the user to destroy the
coroutine frame incorrectly in case of use-after-free happens. But we
can't do so with stack unwinding.
So after this patch, we won't think the exceptional terminator don't
leak the coroutine handle unconditionally. Instead, we think the
exceptional terminator will leak the coroutine handle too if the
coroutine is leaked somewhere along the search path.
Concretely for C++, we can think the exceptional terminator is not
special any more. Maybe this may cause some performance regressions.
But I've tested the motivating example (std::generator). And on the
other side, the coroutine elision is a middle end opitmization and not
a language feature. So we don't think we should blame such regressions
especially we are correcting the miscompilations.
(cherry picked from commit 7037331a2f05990cd59f35a7c0f6ce87c0f3cb5f)
Commit: a4bf0d98670d3d7694ee8f065bed68de8d8f1f75
https://github.com/llvm/llvm-project/commit/a4bf0d98670d3d7694ee8f065bed68de8d8f1f75
Author: Denis Revunov <revunov.denis at huawei-partners.com>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
M bolt/runtime/common.h
M bolt/runtime/instr.cpp
Log Message:
-----------
[BOLT][Instrumentation] Keep profile open in WatchProcess
When a binary is instrumented with --instrumentation-sleep-time and
instrumentation-wait-forks options and lauched, the profile is
periodically written until all the forks die. The problem is that we
cannot wait for the whole process tree, and we have no way to tell when
it's safe to read the profile. Hovewer, if we keep profile open
throughout the life of the process tree, we can use fuser to determine
when writing is finished.
Reviewed By: rafauler
Differential Revision: https://reviews.llvm.org/D154436
(cherry picked from commit a799298152e3ef08b4919cdaac7a614f7cca9bc6)
Commit: 1856972dfe1d9871697af131759ab1e70402c847
https://github.com/llvm/llvm-project/commit/1856972dfe1d9871697af131759ab1e70402c847
Author: Karl-Johan Johnsson <kalle at kjjohnsson.se>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
M llvm/lib/CodeGen/MachineLICM.cpp
A llvm/test/CodeGen/X86/machine-licm-vs-wineh.mir
Log Message:
-----------
[MachineLICM][WinEH] Don't hoist register reloads out of funclets
This fixes https://github.com/llvm/llvm-project/issues/60766
With MSVC style exception-handling (funclets), no registers are
alive when entering the funclet so they must be reloaded from the
stack. MachineLICM can sometimes hoist such reloads out of the
funclet which is not correct, the register will have been clobbered
when entering the funclet. This can happen in any loop that
contains a try-catch.
This has been tested on x86_64-pc-window-msvc. I'm not sure if
funclets work the same on the other windows archs.
Reviewed By: rnk, arsenm
Differential Revision: https://reviews.llvm.org/D153337
(cherry picked from commit 917574d5d8beacbefab4d0e6469dac5b50117832)
Commit: dcb7bcff276664c12e1eb05e19e3e845a76b7116
https://github.com/llvm/llvm-project/commit/dcb7bcff276664c12e1eb05e19e3e845a76b7116
Author: Nico Weber <thakis at chromium.org>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
M clang/test/Driver/x86-no-gather-no-scatter.cpp
Log Message:
-----------
clang: Fix x86-no-gather-no-scatter.cpp on macOS after 993bdb047c90e9
On macOS, files are usually below `/Users/...` and clang-cl treats
that as the `/U` flag followed by something instead of as a path.
Put `--` in front of `%s` to make it treat it as a patch, like in
all other tests.
The failure without this change:
x86-no-gather-no-scatter.cpp:4:14: error: NOGATHER: expected string not found in input
// NOGATHER: "-target-feature" "+prefer-no-gather"
^
<stdin>:5:44: note: possible intended match here
clang: warning: 'x86-no-gather-no-scatter.cpp' treated as the '/U' option [-Wslash-u-filename]
^
(cherry picked from commit 547ee1c81fceaabcb7064ed525f11f9e94083f56)
Commit: f1d5ea362577a8a1b5fafe775cf82a449daa3b07
https://github.com/llvm/llvm-project/commit/f1d5ea362577a8a1b5fafe775cf82a449daa3b07
Author: Serge Pavlov <sepavloff at gmail.com>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
M clang/lib/Sema/TreeTransform.h
A clang/test/SemaCXX/template-64605.cpp
Log Message:
-----------
[clang] Set FP options in Sema when instantiating CompoundStmt
When an expression is instantiated, TreeTransform skips ImplicitCastExpr
nodes, assuming they are recreated when the instantiated expression is
built. It breaks functions that use non-default floating-point options,
because they are kept in these ImplicitCastExprs. In this case the
recreated ImplicitCastExpr takes FP options from the current Sema state
and not from AST node.
To fix this issue the FP options in Sema object are set when a compound
statement is cloned in TreeTransform.
This change fixes https://github.com/llvm/llvm-project/issues/64605
([Regression 16 -> 17] Template instantiation ignores FENV_ACCESS being
ON for both definition and instantiation).
Differential Revision: https://reviews.llvm.org/D158158
(cherry picked from commit 0baf85c331090fbe2d2b42214ed0664d55feb0b5)
Commit: e54f48384bb213f2c204c74d4e7e08a13904a9d6
https://github.com/llvm/llvm-project/commit/e54f48384bb213f2c204c74d4e7e08a13904a9d6
Author: Serge Pavlov <sepavloff at gmail.com>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
M clang/test/SemaCXX/template-64605.cpp
Log Message:
-----------
[clang] Run test for concrete target
The test clang/test/SemaCXX/template-64605.cpp uses pragma FENV_ACCESS,
which is not supported on all targets. Restrict it to x86_64 only.
(cherry picked from commit 73e5a70e676850b79f196e01e2194a2485041584)
Compare: https://github.com/llvm/llvm-project/compare/5bd2c0c745d4...e54f48384bb2
More information about the All-commits
mailing list