maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenCXX/stmtexpr.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

269 lines
7.1 KiB
C++
Raw Normal View History

Don't try to spill static allocas when emitting expr cleanups with branches Credit goes to Gor Nishanov for putting together the fix in https://reviews.llvm.org/D33733! This patch is essentially me patching it locally and writing some test cases to convince myself that it was necessary for GNU statement expressions with branches as well as coroutines. I'll ask Gor to land his patch with just the coroutines test. During LValue expression evaluation, references can be bound to anything, really: call results, aggregate temporaries, local variables, global variables, or indirect arguments. We really only want to spill instructions that were emitted as part of expression evaluation, and static allocas are not that. llvm-svn: 304335
2017-06-01 03:59:41 +08:00
// RUN: %clang_cc1 -Wno-unused-value -triple i686-linux-gnu -emit-llvm -o - %s | FileCheck %s
Patch for mis-compile of statement expressions with non-trivial copy constructors. // rdar: //8540501. A test will be added to llvm nightly tests. llvm-svn: 117324
2010-10-26 07:27:26 +08:00
// rdar: //8540501
extern "C" int printf(...);
extern "C" void abort();
struct A
{
int i;
A (int j) : i(j) {printf("this = %p A(%d)\n", this, j);}
A (const A &j) : i(j.i) {printf("this = %p const A&(%d)\n", this, i);}
A& operator= (const A &j) { i = j.i; abort(); return *this; }
~A() { printf("this = %p ~A(%d)\n", this, i); }
};
struct B
{
int i;
B (const A& a) { i = a.i; }
B() {printf("this = %p B()\n", this);}
B (const B &j) : i(j.i) {printf("this = %p const B&(%d)\n", this, i);}
~B() { printf("this = %p ~B(%d)\n", this, i); }
};
A foo(int j)
{
return ({ j ? A(1) : A(0); });
}
void foo2()
{
A b = ({ A a(1); A a1(2); A a2(3); a1; a2; a; });
if (b.i != 1)
abort();
A c = ({ A a(1); A a1(2); A a2(3); a1; a2; a; A a3(4); a2; a3; });
if (c.i != 4)
abort();
}
void foo3()
{
const A &b = ({ A a(1); a; });
if (b.i != 1)
abort();
}
void foo4()
{
Whack a bunch of tests in CodeGenCXX to work on ARM (using ARM ABI). Batch 2 of 3. llvm-svn: 133011
2011-06-15 05:20:53 +08:00
// CHECK: call {{.*}} @_ZN1AC1Ei
// CHECK: call {{.*}} @_ZN1AC1ERKS_
// CHECK: call {{.*}} @_ZN1AD1Ev
// CHECK: call {{.*}} @_ZN1BC1ERK1A
// CHECK: call {{.*}} @_ZN1AD1Ev
Patch for mis-compile of statement expressions with non-trivial copy constructors. // rdar: //8540501. A test will be added to llvm nightly tests. llvm-svn: 117324
2010-10-26 07:27:26 +08:00
const B &b = ({ A a(1); a; });
if (b.i != 1)
abort();
}
int main()
{
foo2();
foo3();
foo4();
return foo(1).i-1;
}
patch to do array-to-pointer conversion in a statement-expression. // rdar: //8600553 llvm-svn: 117479
2010-10-28 04:10:28 +08:00
// rdar: // 8600553
int a[128];
int* foo5() {
// CHECK-NOT: memcpy
// Check that array-to-pointer conversion occurs in a
// statement-expression.
return (({ a; }));
}
Make sure we don't emit invalid IR for StmtExprs with complex cleanups. Fixes <rdar://problem/14074868>. llvm-svn: 183699
2013-06-11 06:04:49 +08:00
// <rdar://problem/14074868>
// Make sure this doesn't crash.
int foo5(bool b) {
int y = 0;
y = ({ A a(1); if (b) goto G; a.i; });
G: return y;
}
Don't assume cleanup emission preserves dominance in expr evaluation Summary: Because of the existence branches out of GNU statement expressions, it is possible that emitting cleanups for a full expression may cause the new insertion point to not be dominated by the result of the inner expression. Consider this example: struct Foo { Foo(); ~Foo(); int x; }; int g(Foo, int); int f(bool cond) { int n = g(Foo(), ({ if (cond) return 0; 42; })); return n; } Before this change, result of the call to 'g' did not dominate its use in the store to 'n'. The early return exit from the statement expression branches to a shared cleanup block, which ends in a switch between the fallthrough destination (the assignment to 'n') or the function exit block. This change solves the problem by spilling and reloading expression evaluation results when any of the active cleanups have branches. I audited the other call sites of enterFullExpression, and they don't appear to keep and Values live across the site of the cleanup, except in ARC code. I wasn't able to create a test case for ARC that exhibits this problem, though. Reviewers: rjmccall, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30590 llvm-svn: 297084
2017-03-07 06:18:34 +08:00
// When we emit a full expression with cleanups that contains branches out of
// the full expression, the result of the inner expression (the call to
// call_with_cleanups in this case) may not dominate the fallthrough destination
// of the shared cleanup block.
//
// In this case the CFG will be a sequence of two diamonds, but the only
// dynamically possible execution paths are both left hand branches and both
// right hand branches. The first diamond LHS will call bar, and the second
// diamond LHS will assign the result to v, but the call to bar does not
// dominate the assignment.
int bar(A, int);
extern "C" int cleanup_exit_scalar(bool b) {
int v = bar(A(1), ({ if (b) return 42; 13; }));
return v;
}
Relax stmtexpr.cpp checks for PPC64 llvm-svn: 297099
2017-03-07 07:49:18 +08:00
// CHECK-LABEL: define{{.*}} i32 @cleanup_exit_scalar({{.*}})
Don't assume cleanup emission preserves dominance in expr evaluation Summary: Because of the existence branches out of GNU statement expressions, it is possible that emitting cleanups for a full expression may cause the new insertion point to not be dominated by the result of the inner expression. Consider this example: struct Foo { Foo(); ~Foo(); int x; }; int g(Foo, int); int f(bool cond) { int n = g(Foo(), ({ if (cond) return 0; 42; })); return n; } Before this change, result of the call to 'g' did not dominate its use in the store to 'n'. The early return exit from the statement expression branches to a shared cleanup block, which ends in a switch between the fallthrough destination (the assignment to 'n') or the function exit block. This change solves the problem by spilling and reloading expression evaluation results when any of the active cleanups have branches. I audited the other call sites of enterFullExpression, and they don't appear to keep and Values live across the site of the cleanup, except in ARC code. I wasn't able to create a test case for ARC that exhibits this problem, though. Reviewers: rjmccall, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30590 llvm-svn: 297084
2017-03-07 06:18:34 +08:00
// CHECK: call {{.*}} @_ZN1AC1Ei
// Spill after bar.
Relax stmtexpr.cpp checks for PPC64 llvm-svn: 297099
2017-03-07 07:49:18 +08:00
// CHECK: %[[v:[^ ]*]] = call{{.*}} i32 @_Z3bar1Ai({{.*}})
Don't assume cleanup emission preserves dominance in expr evaluation Summary: Because of the existence branches out of GNU statement expressions, it is possible that emitting cleanups for a full expression may cause the new insertion point to not be dominated by the result of the inner expression. Consider this example: struct Foo { Foo(); ~Foo(); int x; }; int g(Foo, int); int f(bool cond) { int n = g(Foo(), ({ if (cond) return 0; 42; })); return n; } Before this change, result of the call to 'g' did not dominate its use in the store to 'n'. The early return exit from the statement expression branches to a shared cleanup block, which ends in a switch between the fallthrough destination (the assignment to 'n') or the function exit block. This change solves the problem by spilling and reloading expression evaluation results when any of the active cleanups have branches. I audited the other call sites of enterFullExpression, and they don't appear to keep and Values live across the site of the cleanup, except in ARC code. I wasn't able to create a test case for ARC that exhibits this problem, though. Reviewers: rjmccall, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30590 llvm-svn: 297084
2017-03-07 06:18:34 +08:00
// CHECK-NEXT: store i32 %[[v]], i32* %[[tmp:[^, ]*]]
// Do cleanup.
// CHECK: call {{.*}} @_ZN1AD1Ev
// CHECK: switch
// Reload before v assignment.
// CHECK: %[[v:[^ ]*]] = load i32, i32* %[[tmp]]
// CHECK-NEXT: store i32 %[[v]], i32* %v
// No need to spill when the expression result is a constant, constants don't
// have dominance problems.
extern "C" int cleanup_exit_scalar_constant(bool b) {
int v = (A(1), (void)({ if (b) return 42; 0; }), 13);
return v;
}
Relax stmtexpr.cpp checks for PPC64 llvm-svn: 297099
2017-03-07 07:49:18 +08:00
// CHECK-LABEL: define{{.*}} i32 @cleanup_exit_scalar_constant({{.*}})
Don't assume cleanup emission preserves dominance in expr evaluation Summary: Because of the existence branches out of GNU statement expressions, it is possible that emitting cleanups for a full expression may cause the new insertion point to not be dominated by the result of the inner expression. Consider this example: struct Foo { Foo(); ~Foo(); int x; }; int g(Foo, int); int f(bool cond) { int n = g(Foo(), ({ if (cond) return 0; 42; })); return n; } Before this change, result of the call to 'g' did not dominate its use in the store to 'n'. The early return exit from the statement expression branches to a shared cleanup block, which ends in a switch between the fallthrough destination (the assignment to 'n') or the function exit block. This change solves the problem by spilling and reloading expression evaluation results when any of the active cleanups have branches. I audited the other call sites of enterFullExpression, and they don't appear to keep and Values live across the site of the cleanup, except in ARC code. I wasn't able to create a test case for ARC that exhibits this problem, though. Reviewers: rjmccall, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30590 llvm-svn: 297084
2017-03-07 06:18:34 +08:00
// CHECK: store i32 13, i32* %v
// Check for the same bug for lvalue expression evaluation kind.
// FIXME: What about non-reference lvalues, like bitfield lvalues and vector
// lvalues?
int &getref();
extern "C" int cleanup_exit_lvalue(bool cond) {
int &r = (A(1), ({ if (cond) return 0; (void)0; }), getref());
return r;
}
Relax stmtexpr.cpp checks for PPC64 llvm-svn: 297099
2017-03-07 07:49:18 +08:00
// CHECK-LABEL: define{{.*}} i32 @cleanup_exit_lvalue({{.*}})
Don't assume cleanup emission preserves dominance in expr evaluation Summary: Because of the existence branches out of GNU statement expressions, it is possible that emitting cleanups for a full expression may cause the new insertion point to not be dominated by the result of the inner expression. Consider this example: struct Foo { Foo(); ~Foo(); int x; }; int g(Foo, int); int f(bool cond) { int n = g(Foo(), ({ if (cond) return 0; 42; })); return n; } Before this change, result of the call to 'g' did not dominate its use in the store to 'n'. The early return exit from the statement expression branches to a shared cleanup block, which ends in a switch between the fallthrough destination (the assignment to 'n') or the function exit block. This change solves the problem by spilling and reloading expression evaluation results when any of the active cleanups have branches. I audited the other call sites of enterFullExpression, and they don't appear to keep and Values live across the site of the cleanup, except in ARC code. I wasn't able to create a test case for ARC that exhibits this problem, though. Reviewers: rjmccall, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30590 llvm-svn: 297084
2017-03-07 06:18:34 +08:00
// CHECK: call {{.*}} @_ZN1AC1Ei
// Spill after bar.
[CGCall] Annotate references with "align" attribute. If we're going to assume references are dereferenceable, we should also assume they're aligned: otherwise, we can't actually dereference them. See also D80072. Differential Revision: https://reviews.llvm.org/D80166
2020-05-19 02:29:11 +08:00
// CHECK: %[[v:[^ ]*]] = call nonnull align 4 dereferenceable(4) i32* @_Z6getrefv({{.*}})
Don't assume cleanup emission preserves dominance in expr evaluation Summary: Because of the existence branches out of GNU statement expressions, it is possible that emitting cleanups for a full expression may cause the new insertion point to not be dominated by the result of the inner expression. Consider this example: struct Foo { Foo(); ~Foo(); int x; }; int g(Foo, int); int f(bool cond) { int n = g(Foo(), ({ if (cond) return 0; 42; })); return n; } Before this change, result of the call to 'g' did not dominate its use in the store to 'n'. The early return exit from the statement expression branches to a shared cleanup block, which ends in a switch between the fallthrough destination (the assignment to 'n') or the function exit block. This change solves the problem by spilling and reloading expression evaluation results when any of the active cleanups have branches. I audited the other call sites of enterFullExpression, and they don't appear to keep and Values live across the site of the cleanup, except in ARC code. I wasn't able to create a test case for ARC that exhibits this problem, though. Reviewers: rjmccall, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30590 llvm-svn: 297084
2017-03-07 06:18:34 +08:00
// CHECK-NEXT: store i32* %[[v]], i32** %[[tmp:[^, ]*]]
// Do cleanup.
// CHECK: call {{.*}} @_ZN1AD1Ev
// CHECK: switch
// Reload before v assignment.
// CHECK: %[[v:[^ ]*]] = load i32*, i32** %[[tmp]]
// CHECK-NEXT: store i32* %[[v]], i32** %r
Don't try to spill static allocas when emitting expr cleanups with branches Credit goes to Gor Nishanov for putting together the fix in https://reviews.llvm.org/D33733! This patch is essentially me patching it locally and writing some test cases to convince myself that it was necessary for GNU statement expressions with branches as well as coroutines. I'll ask Gor to land his patch with just the coroutines test. During LValue expression evaluation, references can be bound to anything, really: call results, aggregate temporaries, local variables, global variables, or indirect arguments. We really only want to spill instructions that were emitted as part of expression evaluation, and static allocas are not that. llvm-svn: 304335
2017-06-01 03:59:41 +08:00
// Bind the reference to a byval argument. It is not an instruction or Constant,
// so it's a bit of a corner case.
struct ByVal { int x[3]; };
extern "C" int cleanup_exit_lvalue_byval(bool cond, ByVal arg) {
ByVal &r = (A(1), ({ if (cond) return 0; (void)ByVal(); }), arg);
return r.x[0];
}
LLVM IR: Generate new-style byval-with-Type from Clang LLVM IR recently added a Type parameter to the byval Attribute, so that when pointers become opaque and no longer have an element type the information will still be present in IR. For now the Type parameter is optional (which is why Clang didn't need this change at the time), but it will become mandatory soon. llvm-svn: 362652
2019-06-06 05:12:14 +08:00
// CHECK-LABEL: define{{.*}} i32 @cleanup_exit_lvalue_byval({{.*}}, %struct.ByVal* byval(%struct.ByVal) align 4 %arg)
Don't try to spill static allocas when emitting expr cleanups with branches Credit goes to Gor Nishanov for putting together the fix in https://reviews.llvm.org/D33733! This patch is essentially me patching it locally and writing some test cases to convince myself that it was necessary for GNU statement expressions with branches as well as coroutines. I'll ask Gor to land his patch with just the coroutines test. During LValue expression evaluation, references can be bound to anything, really: call results, aggregate temporaries, local variables, global variables, or indirect arguments. We really only want to spill instructions that were emitted as part of expression evaluation, and static allocas are not that. llvm-svn: 304335
2017-06-01 03:59:41 +08:00
// CHECK: call {{.*}} @_ZN1AC1Ei
// CHECK: call {{.*}} @_ZN1AD1Ev
// CHECK: switch
// CHECK: store %struct.ByVal* %arg, %struct.ByVal** %r
// Bind the reference to a local variable. We don't need to spill it. Binding a
// reference to it doesn't generate any instructions.
extern "C" int cleanup_exit_lvalue_local(bool cond) {
int local = 42;
int &r = (A(1), ({ if (cond) return 0; (void)0; }), local);
return r;
}
// CHECK-LABEL: define{{.*}} i32 @cleanup_exit_lvalue_local({{.*}})
// CHECK: %local = alloca i32
// CHECK: store i32 42, i32* %local
// CHECK: call {{.*}} @_ZN1AC1Ei
// CHECK-NOT: store i32* %local
// CHECK: call {{.*}} @_ZN1AD1Ev
// CHECK: switch
// CHECK: store i32* %local, i32** %r, align 4
Don't assume cleanup emission preserves dominance in expr evaluation Summary: Because of the existence branches out of GNU statement expressions, it is possible that emitting cleanups for a full expression may cause the new insertion point to not be dominated by the result of the inner expression. Consider this example: struct Foo { Foo(); ~Foo(); int x; }; int g(Foo, int); int f(bool cond) { int n = g(Foo(), ({ if (cond) return 0; 42; })); return n; } Before this change, result of the call to 'g' did not dominate its use in the store to 'n'. The early return exit from the statement expression branches to a shared cleanup block, which ends in a switch between the fallthrough destination (the assignment to 'n') or the function exit block. This change solves the problem by spilling and reloading expression evaluation results when any of the active cleanups have branches. I audited the other call sites of enterFullExpression, and they don't appear to keep and Values live across the site of the cleanup, except in ARC code. I wasn't able to create a test case for ARC that exhibits this problem, though. Reviewers: rjmccall, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30590 llvm-svn: 297084
2017-03-07 06:18:34 +08:00
// We handle ExprWithCleanups for complex evaluation type separately, and it had
// the same bug.
_Complex float bar_complex(A, int);
extern "C" int cleanup_exit_complex(bool b) {
_Complex float v = bar_complex(A(1), ({ if (b) return 42; 13; }));
Sema: disable implicit conversion from _Complex to real types in C++. Converting a _Complex type to a real one simply discards the imaginary part. This can easily lead to loss of information so for safety (and GCC compatibility) this patch disallows that when the conversion would be implicit. The one exception is bool, which actually compares both real and imaginary parts and so is safe. llvm-svn: 310427
2017-08-09 07:18:05 +08:00
return (float)v;
Don't assume cleanup emission preserves dominance in expr evaluation Summary: Because of the existence branches out of GNU statement expressions, it is possible that emitting cleanups for a full expression may cause the new insertion point to not be dominated by the result of the inner expression. Consider this example: struct Foo { Foo(); ~Foo(); int x; }; int g(Foo, int); int f(bool cond) { int n = g(Foo(), ({ if (cond) return 0; 42; })); return n; } Before this change, result of the call to 'g' did not dominate its use in the store to 'n'. The early return exit from the statement expression branches to a shared cleanup block, which ends in a switch between the fallthrough destination (the assignment to 'n') or the function exit block. This change solves the problem by spilling and reloading expression evaluation results when any of the active cleanups have branches. I audited the other call sites of enterFullExpression, and they don't appear to keep and Values live across the site of the cleanup, except in ARC code. I wasn't able to create a test case for ARC that exhibits this problem, though. Reviewers: rjmccall, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30590 llvm-svn: 297084
2017-03-07 06:18:34 +08:00
}
Relax stmtexpr.cpp checks for PPC64 llvm-svn: 297099
2017-03-07 07:49:18 +08:00
// CHECK-LABEL: define{{.*}} i32 @cleanup_exit_complex({{.*}})
Don't assume cleanup emission preserves dominance in expr evaluation Summary: Because of the existence branches out of GNU statement expressions, it is possible that emitting cleanups for a full expression may cause the new insertion point to not be dominated by the result of the inner expression. Consider this example: struct Foo { Foo(); ~Foo(); int x; }; int g(Foo, int); int f(bool cond) { int n = g(Foo(), ({ if (cond) return 0; 42; })); return n; } Before this change, result of the call to 'g' did not dominate its use in the store to 'n'. The early return exit from the statement expression branches to a shared cleanup block, which ends in a switch between the fallthrough destination (the assignment to 'n') or the function exit block. This change solves the problem by spilling and reloading expression evaluation results when any of the active cleanups have branches. I audited the other call sites of enterFullExpression, and they don't appear to keep and Values live across the site of the cleanup, except in ARC code. I wasn't able to create a test case for ARC that exhibits this problem, though. Reviewers: rjmccall, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30590 llvm-svn: 297084
2017-03-07 06:18:34 +08:00
// CHECK: call {{.*}} @_ZN1AC1Ei
// Spill after bar.
// CHECK: call {{.*}} @_Z11bar_complex1Ai({{.*}})
// CHECK: store float %{{.*}}, float* %[[tmp1:[^, ]*]]
// CHECK: store float %{{.*}}, float* %[[tmp2:[^, ]*]]
// Do cleanup.
// CHECK: call {{.*}} @_ZN1AD1Ev
// CHECK: switch
// Reload before v assignment.
// CHECK: %[[v1:[^ ]*]] = load float, float* %[[tmp1]]
// CHECK: %[[v2:[^ ]*]] = load float, float* %[[tmp2]]
// CHECK: store float %[[v1]], float* %v.realp
// CHECK: store float %[[v2]], float* %v.imagp
PR40642: Fix determination of whether the final statement of a statement expression is a discarded-value expression. Summary: We used to get this wrong in three ways: 1) During parsing, an expression-statement followed by the }) ending a statement expression was always treated as producing the value of the statement expression. That's wrong for ({ if (1) expr; }) 2) During template instantiation, various kinds of statement (most statements not appearing directly in a compound-statement) were not treated as discarded-value expressions, resulting in missing volatile loads (etc). 3) In all contexts, an expression-statement with attributes was not treated as producing the value of the statement expression, eg ({ [[attr]] expr; }). Also fix incorrect enforcement of OpenMP rule that directives can "only be placed in the program at a position where ignoring or deleting the directive would result in a program with correct syntax". In particular, a label (be it goto, case, or default) should not affect whether directives are permitted. Reviewers: aaron.ballman, rjmccall Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57984 llvm-svn: 354090
2019-02-15 08:27:53 +08:00
extern "C" void then(int);
// CHECK-LABEL: @{{.*}}volatile_load
void volatile_load() {
volatile int n;
// CHECK-NOT: load volatile
// CHECK: load volatile
// CHECK-NOT: load volatile
({n;});
// CHECK-LABEL: @then(i32 1)
then(1);
// CHECK-NOT: load volatile
// CHECK: load volatile
// CHECK-NOT: load volatile
({goto lab; lab: n;});
// CHECK-LABEL: @then(i32 2)
then(2);
// CHECK-NOT: load volatile
// CHECK: load volatile
// CHECK-NOT: load volatile
({[[gsl::suppress("foo")]] n;});
// CHECK-LABEL: @then(i32 3)
then(3);
// CHECK-NOT: load volatile
// CHECK: load volatile
// CHECK-NOT: load volatile
({if (true) n;});
// CHECK: }
}
// CHECK-LABEL: @{{.*}}volatile_load_template
template<typename T>
void volatile_load_template() {
volatile T n;
// CHECK-NOT: load volatile
// CHECK: load volatile
// CHECK-NOT: load volatile
({n;});
// CHECK-LABEL: @then(i32 1)
then(1);
// CHECK-NOT: load volatile
// CHECK: load volatile
// CHECK-NOT: load volatile
({goto lab; lab: n;});
// CHECK-LABEL: @then(i32 2)
then(2);
// CHECK-NOT: load volatile
// CHECK: load volatile
// CHECK-NOT: load volatile
({[[gsl::suppress("foo")]] n;});
// CHECK-LABEL: @then(i32 3)
then(3);
// CHECK-NOT: load volatile
// CHECK: load volatile
// CHECK-NOT: load volatile
({if (true) n;});
// CHECK: }
}
template void volatile_load_template<int>();