================
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -gkey-instructions
-gno-column-info -x c++ %s -debug-info-kind=line-tables-only -emit-llvm -o - \
+// RUN: | FileCheck %s --implicit-check-not atomGroup --implicit-check-not
atomRank
+
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -gkey-instructions
-gno-column-info -x c %s -debug-info-kind=line-tables-only -emit-llvm -o - \
+// RUN: | FileCheck %s --implicit-check-not atomGroup --implicit-check-not
atomRank
+
+typedef struct {
+ struct{} a;
+ double b;
+} s1;
+
+s1 f(int z, ...) {
+ __builtin_va_list list;
+ __builtin_va_start(list, z);
+// CHECK: vaarg.end:
+// CHECK-NEXT: %vaarg.addr = phi ptr
+// CHECK-NEXT: call void @llvm.memcpy{{.*}}, !dbg [[G1R1:!.*]]
----------------
OCHyams wrote:
The comment from test return.c covers this case:
```
// Check the stores to `retval` allocas and branches to `return` block are in
// the same atom group. They are both rank 1, which could in theory introduce
// an extra step in some optimized code. This low risk currently feels an
// acceptable for keeping the code a bit simpler (as opposed to adding
// scaffolding to make the store rank 2).
```
(But in this case the "store to retval" is a memcpy).
We want them in the same group because these are all instructions generated
from the source `return some_value`.
https://github.com/llvm/llvm-project/pull/134652
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
