r176654 - Evaluate compound literals directly into the result aggregate

[Benjamin Kramer]

On 07.03.2013, at 22:36, John McCall <rjmccall at apple.com> wrote:

> Author: rjmccall
> Date: Thu Mar  7 15:36:54 2013
> New Revision: 176654
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=176654&view=rev
> Log:
> Evaluate compound literals directly into the result aggregate
> when that aggregate isn't potentially aliased.
> 
> Modified:
>    cfe/trunk/lib/CodeGen/CGExprAgg.cpp
>    cfe/trunk/test/CodeGen/compound-literal.c
> 
> Modified: cfe/trunk/lib/CodeGen/CGExprAgg.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExprAgg.cpp?rev=176654&r1=176653&r2=176654&view=diff
> ==============================================================================
> --- cfe/trunk/lib/CodeGen/CGExprAgg.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGExprAgg.cpp Thu Mar  7 15:36:54 2013
> @@ -531,12 +531,10 @@ void AggExprEmitter::VisitOpaqueValueExp
> 
> void
> AggExprEmitter::VisitCompoundLiteralExpr(CompoundLiteralExpr *E) {
> -  if (E->getType().isPODType(CGF.getContext())) {
> +  if (Dest.isPotentiallyAliased() &&
> +      E->getType().isPODType(CGF.getContext())) {

Does this really depend on the C++ version in use or could it always use the more lenient C++11 definition of POD?

- Ben

>     // For a POD type, just emit a load of the lvalue + a copy, because our
>     // compound literal might alias the destination.
> -    // FIXME: This is a band-aid; the real problem appears to be in our handling
> -    // of assignments, where we store directly into the LHS without checking
> -    // whether anything in the RHS aliases.
>     EmitAggLoadOfLValue(E);
>     return;
>   }
> 
> Modified: cfe/trunk/test/CodeGen/compound-literal.c
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/compound-literal.c?rev=176654&r1=176653&r2=176654&view=diff
> ==============================================================================
> --- cfe/trunk/test/CodeGen/compound-literal.c (original)
> +++ cfe/trunk/test/CodeGen/compound-literal.c Thu Mar  7 15:36:54 2013
> @@ -32,3 +32,37 @@ void f() {
>   s = (S){s.y,s.x};
>   // CHECK-NEXT: ret void
> }
> +
> +// CHECK: define i48 @g(
> +struct G { short x, y, z; };
> +struct G g(int x, int y, int z) {
> +  // CHECK:      [[RESULT:%.*]] = alloca [[G:%.*]], align 2
> +  // CHECK-NEXT: [[X:%.*]] = alloca i32, align 4
> +  // CHECK-NEXT: [[Y:%.*]] = alloca i32, align 4
> +  // CHECK-NEXT: [[Z:%.*]] = alloca i32, align 4
> +  // CHECK-NEXT: [[COERCE_TEMP:%.*]] = alloca i48
> +  // CHECK-NEXT: store i32
> +  // CHECK-NEXT: store i32
> +  // CHECK-NEXT: store i32
> +
> +  // Evaluate the compound literal directly in the result value slot.
> +  // CHECK-NEXT: [[T0:%.*]] = getelementptr inbounds [[G]]* [[RESULT]], i32 0, i32 0
> +  // CHECK-NEXT: [[T1:%.*]] = load i32* [[X]], align 4
> +  // CHECK-NEXT: [[T2:%.*]] = trunc i32 [[T1]] to i16
> +  // CHECK-NEXT: store i16 [[T2]], i16* [[T0]], align 2
> +  // CHECK-NEXT: [[T0:%.*]] = getelementptr inbounds [[G]]* [[RESULT]], i32 0, i32 1
> +  // CHECK-NEXT: [[T1:%.*]] = load i32* [[Y]], align 4
> +  // CHECK-NEXT: [[T2:%.*]] = trunc i32 [[T1]] to i16
> +  // CHECK-NEXT: store i16 [[T2]], i16* [[T0]], align 2
> +  // CHECK-NEXT: [[T0:%.*]] = getelementptr inbounds [[G]]* [[RESULT]], i32 0, i32 2
> +  // CHECK-NEXT: [[T1:%.*]] = load i32* [[Z]], align 4
> +  // CHECK-NEXT: [[T2:%.*]] = trunc i32 [[T1]] to i16
> +  // CHECK-NEXT: store i16 [[T2]], i16* [[T0]], align 2
> +  return (struct G) { x, y, z };
> +
> +  // CHECK-NEXT: [[T0:%.*]] = bitcast i48* [[COERCE_TEMP]] to i8*
> +  // CHECK-NEXT: [[T1:%.*]] = bitcast [[G]]* [[RESULT]] to i8*
> +  // CHECK-NEXT: call void @llvm.memcpy.p0i8.p0i8.i64(i8* [[T0]], i8* [[T1]], i64 6
> +  // CHECK-NEXT: [[T0:%.*]] = load i48* [[COERCE_TEMP]]
> +  // CHECK-NEXT: ret i48 [[T0]]
> +}
> 
> 
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits