@@ -1047,122 +1019,19 @@ RValue CodeGenFunction::EmitAtomicExpr(AtomicExpr *E) {
Dest = Atomics.castToAtomicIntPointer(Dest);
}
- // Use a library call. See: http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary .
- if (UseLibcall) {
-bool UseOptimizedLibcall = false;
-
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/73176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1047,122 +1019,19 @@ RValue CodeGenFunction::EmitAtomicExpr(AtomicExpr *E) {
Dest = Atomics.castToAtomicIntPointer(Dest);
}
- // Use a library call. See: http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary .
- if (UseLibcall) {
-bool UseOptimizedLibcall = false;
-
@@ -1,120 +1,147 @@
-// RUN: %clang_cc1 < %s -triple armv5e-none-linux-gnueabi -emit-llvm -O1 |
FileCheck %s
-
-// FIXME: This file should not be checking -O1 output.
-// Ie, it is testing many IR optimizer passes as part of front-end
verification.
+// RUN: %clang_cc1 < %s -trip
@@ -7,22 +7,19 @@
// RUN: %clang_cc1 -triple riscv64 -target-feature +a -O1 -emit-llvm %s -o - \
// RUN: | FileCheck %s -check-prefix=RV64IA
-// This test demonstrates that MaxAtomicInlineWidth is set appropriately when
jyknight wrote:
I think this test nee
https://github.com/jyknight commented:
Overall, I think this is a great improvement.
And I believe it should be correct to do now, after fixing the backends'
MaxAtomicSizeInBitsSupported in #75703 #75185 #75112 #74385 #74389, and fixing
Clang's propagation of alignment to atomicrmw/cmpxchg in
@@ -23,7 +23,7 @@ typedef __int128_t int128_t;
// PPC64-QUADWORD-ATOMICS:[[TMP3:%.*]] = load atomic i128, ptr
[[TMP1:%.*]] acquire, align 16
//
// PPC64-LABEL: @test_load(
-// PPC64:call void @__atomic_load(i64 noundef 16, ptr noundef
[[TMP3:%.*]], ptr noundef [[TMP4:
@@ -33,9 +33,9 @@ void test_i32_atomics(_Atomic(int32_t) * a, int32_t b) {
}
void test_i64_atomics(_Atomic(int64_t) * a, int64_t b) {
- // LA32: call i64 @__atomic_load_8
- // LA32: call void @__atomic_store_8
- // LA32: call i64 @__atomic_fetch_add_8
+ // LA32: load atomi
@@ -33,9 +33,9 @@ void test_i32_atomics(_Atomic(int32_t) * a, int32_t b) {
}
void test_i64_atomics(_Atomic(int64_t) * a, int64_t b) {
- // LA32: call i64 @__atomic_load_8
- // LA32: call void @__atomic_store_8
- // LA32: call i64 @__atomic_fetch_add_8
+ // LA32: load atomi
@@ -1047,122 +1019,19 @@ RValue CodeGenFunction::EmitAtomicExpr(AtomicExpr *E) {
Dest = Atomics.castToAtomicIntPointer(Dest);
}
- // Use a library call. See: http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary .
- if (UseLibcall) {
-bool UseOptimizedLibcall = false;
-
https://github.com/Logikable edited
https://github.com/llvm/llvm-project/pull/73176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Logikable wrote:
I've rewritten a part of this PR to incorporate @arichardson's suggestion. I
wasn't able to find inconsistencies through a cursory review of the backend's
AtomicExpand pass, nor through a small set of tests built for common targets.
How can I find the gaps I missed?
https://g
efriedma-quic wrote:
When I said "inconsistencies", I just meant the way the responsibility for
lowering atomics is split between LLVM and clang; I didn't mean anything was
actually broken.
https://github.com/llvm/llvm-project/pull/73176
___
cfe-comm
https://github.com/MaskRay closed
https://github.com/llvm/llvm-project/pull/73176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
I'm pretty certain this patch broke the [Solaris/sparcv9
buildbot](https://lab.llvm.org/buildbot/#/builders/72/builds/2541).
https://github.com/llvm/llvm-project/pull/73176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://l
rorth wrote:
Confirmed: reverting the patch locally restores the build.
https://github.com/llvm/llvm-project/pull/73176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Logikable wrote:
https://reviews.llvm.org/D118021 likely related, looking into this.
https://github.com/llvm/llvm-project/pull/73176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
The libcalls per se wouldn't be a problem since on 32-bit Solaris/sparc
`-latomic` is always linked due to that. However, the `__sync_*` libcalls
aren't defined in `libatomic.so`, thus the link failure.
https://github.com/llvm/llvm-project/pull/73176
_
efriedma-quic wrote:
Looks like a bug in the SPARC backend.
https://github.com/llvm/llvm-project/pull/73176#pullrequestreview-1811677691
indicated that atomic expansion was working correctly for all backends, but I
guess it isn't working correctly on SPARC.
https://github.com/llvm/llvm-proj
jyknight wrote:
What config is this bot using? Is it "-target sparc-solaris -mcpu=v9" (that is:
32-bit sparc, but with v9 cpu available)?
I see that SparcV9TargetInfo sets MaxAtomicInlineWidth to 64 unconditionally.
But, the message `warning: large atomic operation may incur significant
perfo
jrtc27 wrote:
Part of that confusion comes from SPARC's own naming. V9 is the CPU, but a V9
CPU being used for 32-bit code is called V8+...
https://github.com/llvm/llvm-project/pull/73176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https:/
Logikable wrote:
Gentle bump on this. Is there anything I can do now to make this easier to
review?
https://github.com/llvm/llvm-project/pull/73176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo
https://github.com/jyknight approved this pull request.
Sorry for the delay. This looks good to me now!
https://github.com/llvm/llvm-project/pull/73176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listi
jyknight wrote:
BTW, please don't rebase/amend commits and force-push, it makes a it extremely
difficult to review the changes since the previous review -- especially if the
new changes are commingled with a rebase.
Much better to simply push new commits on top of your existing branch. And if
https://github.com/Logikable edited
https://github.com/llvm/llvm-project/pull/73176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/arichardson commented:
Overall this looks great to me, very happy to see reduced duplication between
clang and llvm.
It would be great if we could just emit the atomic IR in all cases but
unfortunately non-power-of-two sizes result in a verifier error. We could
probably emi
https://github.com/Logikable updated
https://github.com/llvm/llvm-project/pull/73176
>From 9dfcc46c600a0c4720553faf7e070862650792bc Mon Sep 17 00:00:00 2001
From: Sean Luchen
Date: Fri, 17 Nov 2023 17:29:52 +
Subject: [PATCH] [clang][CodeGen] Emit atomic IR in place of optimized
libcalls.
Logikable wrote:
Updated with suggestions. How does this look?
https://github.com/llvm/llvm-project/pull/73176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
28 matches
Mail list logo
