maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGen/x86_64-floatvectors.c

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

132 lines
5.4 KiB
C
Raw Normal View History

[CodeGen][va_args] Correct Vector Struct va-arg 'in_reg' code gen When trying to track down a different bug, we discovered that calling __builtin_va_arg on a vec3f type caused the SROA pass to issue a warning that there was an illegal access. Further research showed that the vec3f type is alloca'ed as size '12', but the _builtin_va_arg code on x86_64 was always loading this out of registers as {double, double}. Thus, the 2nd store into the vec3f was storing in bytes 12-15! This patch alters the original implementation which always assumed {double, double} to use the actual coerced type instead, so the LLVM-IR generated is a load/GEP/store of a <2 x float> and a float, rather than a double and a double. Tests were added for all combinations I could think of that would fit in 2 FP registers, and all work exactly as expected. Differential Revision: https://reviews.llvm.org/D42811 llvm-svn: 324098
2018-02-02 23:53:35 +08:00
// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s | \
// RUN: FileCheck %s
// This test validates that the inreg branch generation for __builtin_va_arg
// does not exceed the alloca size of the type, which can cause the SROA pass to
// eliminate the assignment.
typedef struct { float x, y, z; } vec3f;
double Vec3FTest(__builtin_va_list ap) {
vec3f vec = __builtin_va_arg(ap, vec3f);
return vec.x + vec.y + vec.z;
}
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK: define double @Vec3FTest
[CodeGen][va_args] Correct Vector Struct va-arg 'in_reg' code gen When trying to track down a different bug, we discovered that calling __builtin_va_arg on a vec3f type caused the SROA pass to issue a warning that there was an illegal access. Further research showed that the vec3f type is alloca'ed as size '12', but the _builtin_va_arg code on x86_64 was always loading this out of registers as {double, double}. Thus, the 2nd store into the vec3f was storing in bytes 12-15! This patch alters the original implementation which always assumed {double, double} to use the actual coerced type instead, so the LLVM-IR generated is a load/GEP/store of a <2 x float> and a float, rather than a double and a double. Tests were added for all combinations I could think of that would fit in 2 FP registers, and all work exactly as expected. Differential Revision: https://reviews.llvm.org/D42811 llvm-svn: 324098
2018-02-02 23:53:35 +08:00
// CHECK: vaarg.in_reg:
// CHECK: [[Vec3FLoad1:%.*]] = load <2 x float>, <2 x float>*
// CHECK: [[Vec3FGEP1:%.*]] = getelementptr inbounds { <2 x float>, float }, { <2 x float>, float }* {{%.*}}, i32 0, i32 0
// CHECK: store <2 x float> [[Vec3FLoad1]], <2 x float>* [[Vec3FGEP1]]
// CHECK: [[Vec3FLoad2:%.*]] = load float, float*
// CHECK: [[Vec3FGEP2:%.*]] = getelementptr inbounds { <2 x float>, float }, { <2 x float>, float }* {{%.*}}, i32 0, i32 1
// CHECK: store float [[Vec3FLoad2]], float* [[Vec3FGEP2]]
// CHECK: vaarg.in_mem:
typedef struct { float x, y, z, q; } vec4f;
double Vec4FTest(__builtin_va_list ap) {
vec4f vec = __builtin_va_arg(ap, vec4f);
return vec.x + vec.y + vec.z + vec.q;
}
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK: define double @Vec4FTest
[CodeGen][va_args] Correct Vector Struct va-arg 'in_reg' code gen When trying to track down a different bug, we discovered that calling __builtin_va_arg on a vec3f type caused the SROA pass to issue a warning that there was an illegal access. Further research showed that the vec3f type is alloca'ed as size '12', but the _builtin_va_arg code on x86_64 was always loading this out of registers as {double, double}. Thus, the 2nd store into the vec3f was storing in bytes 12-15! This patch alters the original implementation which always assumed {double, double} to use the actual coerced type instead, so the LLVM-IR generated is a load/GEP/store of a <2 x float> and a float, rather than a double and a double. Tests were added for all combinations I could think of that would fit in 2 FP registers, and all work exactly as expected. Differential Revision: https://reviews.llvm.org/D42811 llvm-svn: 324098
2018-02-02 23:53:35 +08:00
// CHECK: vaarg.in_reg:
// CHECK: [[Vec4FLoad1:%.*]] = load <2 x float>, <2 x float>*
// CHECK: [[Vec4FGEP1:%.*]] = getelementptr inbounds { <2 x float>, <2 x float> }, { <2 x float>, <2 x float> }* {{%.*}}, i32 0, i32 0
// CHECK: store <2 x float> [[Vec4FLoad1]], <2 x float>* [[Vec4FGEP1]]
// CHECK: [[Vec4FLoad2:%.*]] = load <2 x float>, <2 x float>*
// CHECK: [[Vec4FGEP2:%.*]] = getelementptr inbounds { <2 x float>, <2 x float> }, { <2 x float>, <2 x float> }* {{%.*}}, i32 0, i32 1
// CHECK: store <2 x float> [[Vec4FLoad2]], <2 x float>* [[Vec4FGEP2]]
// CHECK: vaarg.in_mem:
typedef struct { double x, y; } vec2d;
double Vec2DTest(__builtin_va_list ap) {
vec2d vec = __builtin_va_arg(ap, vec2d);
return vec.x + vec.y;
}
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK: define double @Vec2DTest
[CodeGen][va_args] Correct Vector Struct va-arg 'in_reg' code gen When trying to track down a different bug, we discovered that calling __builtin_va_arg on a vec3f type caused the SROA pass to issue a warning that there was an illegal access. Further research showed that the vec3f type is alloca'ed as size '12', but the _builtin_va_arg code on x86_64 was always loading this out of registers as {double, double}. Thus, the 2nd store into the vec3f was storing in bytes 12-15! This patch alters the original implementation which always assumed {double, double} to use the actual coerced type instead, so the LLVM-IR generated is a load/GEP/store of a <2 x float> and a float, rather than a double and a double. Tests were added for all combinations I could think of that would fit in 2 FP registers, and all work exactly as expected. Differential Revision: https://reviews.llvm.org/D42811 llvm-svn: 324098
2018-02-02 23:53:35 +08:00
// CHECK: vaarg.in_reg:
// CHECK: [[Vec2DLoad1:%.*]] = load double, double*
// CHECK: [[Vec2DGEP1:%.*]] = getelementptr inbounds { double, double }, { double, double }* {{%.*}}, i32 0, i32 0
// CHECK: store double [[Vec2DLoad1]], double* [[Vec2DGEP1]]
// CHECK: [[Vec2DLoad2:%.*]] = load double, double*
// CHECK: [[Vec2DGEP2:%.*]] = getelementptr inbounds { double, double }, { double, double }* {{%.*}}, i32 0, i32 1
// CHECK: store double [[Vec2DLoad2]], double* [[Vec2DGEP2]]
// CHECK: vaarg.in_mem:
typedef struct {
float x, y;
double z;
} vec2f1d;
double Vec2F1DTest(__builtin_va_list ap) {
vec2f1d vec = __builtin_va_arg(ap, vec2f1d);
return vec.x + vec.y + vec.z;
}
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK: define double @Vec2F1DTest
[CodeGen][va_args] Correct Vector Struct va-arg 'in_reg' code gen When trying to track down a different bug, we discovered that calling __builtin_va_arg on a vec3f type caused the SROA pass to issue a warning that there was an illegal access. Further research showed that the vec3f type is alloca'ed as size '12', but the _builtin_va_arg code on x86_64 was always loading this out of registers as {double, double}. Thus, the 2nd store into the vec3f was storing in bytes 12-15! This patch alters the original implementation which always assumed {double, double} to use the actual coerced type instead, so the LLVM-IR generated is a load/GEP/store of a <2 x float> and a float, rather than a double and a double. Tests were added for all combinations I could think of that would fit in 2 FP registers, and all work exactly as expected. Differential Revision: https://reviews.llvm.org/D42811 llvm-svn: 324098
2018-02-02 23:53:35 +08:00
// CHECK: vaarg.in_reg:
// CHECK: [[Vec2F1DLoad1:%.*]] = load <2 x float>, <2 x float>*
// CHECK: [[Vec2F1DGEP1:%.*]] = getelementptr inbounds { <2 x float>, double }, { <2 x float>, double }* {{%.*}}, i32 0, i32 0
// CHECK: store <2 x float> [[Vec2F1DLoad1]], <2 x float>* [[Vec2F1DGEP1]]
// CHECK: [[Vec2F1DLoad2:%.*]] = load double, double*
// CHECK: [[Vec2F1DGEP2:%.*]] = getelementptr inbounds { <2 x float>, double }, { <2 x float>, double }* {{%.*}}, i32 0, i32 1
// CHECK: store double [[Vec2F1DLoad2]], double* [[Vec2F1DGEP2]]
// CHECK: vaarg.in_mem:
typedef struct {
double x;
float y, z;
} vec1d2f;
double Vec1D2FTest(__builtin_va_list ap) {
vec1d2f vec = __builtin_va_arg(ap, vec1d2f);
return vec.x + vec.y + vec.z;
}
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK: define double @Vec1D2FTest
[CodeGen][va_args] Correct Vector Struct va-arg 'in_reg' code gen When trying to track down a different bug, we discovered that calling __builtin_va_arg on a vec3f type caused the SROA pass to issue a warning that there was an illegal access. Further research showed that the vec3f type is alloca'ed as size '12', but the _builtin_va_arg code on x86_64 was always loading this out of registers as {double, double}. Thus, the 2nd store into the vec3f was storing in bytes 12-15! This patch alters the original implementation which always assumed {double, double} to use the actual coerced type instead, so the LLVM-IR generated is a load/GEP/store of a <2 x float> and a float, rather than a double and a double. Tests were added for all combinations I could think of that would fit in 2 FP registers, and all work exactly as expected. Differential Revision: https://reviews.llvm.org/D42811 llvm-svn: 324098
2018-02-02 23:53:35 +08:00
// CHECK: vaarg.in_reg:
// CHECK: [[Vec1D2FLoad1:%.*]] = load double, double*
// CHECK: [[Vec1D2FGEP1:%.*]] = getelementptr inbounds { double, <2 x float> }, { double, <2 x float> }* {{%.*}}, i32 0, i32 0
// CHECK: store double [[Vec1D2FLoad1]], double* [[Vec1D2FGEP1]]
// CHECK: [[Vec1D2FLoad2:%.*]] = load <2 x float>, <2 x float>*
// CHECK: [[Vec1D2FGEP2:%.*]] = getelementptr inbounds { double, <2 x float> }, { double, <2 x float> }* {{%.*}}, i32 0, i32 1
// CHECK: store <2 x float> [[Vec1D2FLoad2]], <2 x float>* [[Vec1D2FGEP2]]
// CHECK: vaarg.in_mem:
typedef struct {
float x;
double z;
} vec1f1d;
double Vec1F1DTest(__builtin_va_list ap) {
vec1f1d vec = __builtin_va_arg(ap, vec1f1d);
return vec.x + vec.z;
}
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK: define double @Vec1F1DTest
[CodeGen][va_args] Correct Vector Struct va-arg 'in_reg' code gen When trying to track down a different bug, we discovered that calling __builtin_va_arg on a vec3f type caused the SROA pass to issue a warning that there was an illegal access. Further research showed that the vec3f type is alloca'ed as size '12', but the _builtin_va_arg code on x86_64 was always loading this out of registers as {double, double}. Thus, the 2nd store into the vec3f was storing in bytes 12-15! This patch alters the original implementation which always assumed {double, double} to use the actual coerced type instead, so the LLVM-IR generated is a load/GEP/store of a <2 x float> and a float, rather than a double and a double. Tests were added for all combinations I could think of that would fit in 2 FP registers, and all work exactly as expected. Differential Revision: https://reviews.llvm.org/D42811 llvm-svn: 324098
2018-02-02 23:53:35 +08:00
// CHECK: vaarg.in_reg:
// CHECK: [[Vec1F1DLoad1:%.*]] = load float, float*
// CHECK: [[Vec1F1DGEP1:%.*]] = getelementptr inbounds { float, double }, { float, double }* {{%.*}}, i32 0, i32 0
// CHECK: store float [[Vec1F1DLoad1]], float* [[Vec1F1DGEP1]]
// CHECK: [[Vec1F1DLoad2:%.*]] = load double, double*
// CHECK: [[Vec1F1DGEP2:%.*]] = getelementptr inbounds { float, double }, { float, double }* {{%.*}}, i32 0, i32 1
// CHECK: store double [[Vec1F1DLoad2]], double* [[Vec1F1DGEP2]]
// CHECK: vaarg.in_mem:
typedef struct {
double x;
float z;
} vec1d1f;
double Vec1D1FTest(__builtin_va_list ap) {
vec1d1f vec = __builtin_va_arg(ap, vec1d1f);
return vec.x + vec.z;
}
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// CHECK: define double @Vec1D1FTest
[CodeGen][va_args] Correct Vector Struct va-arg 'in_reg' code gen When trying to track down a different bug, we discovered that calling __builtin_va_arg on a vec3f type caused the SROA pass to issue a warning that there was an illegal access. Further research showed that the vec3f type is alloca'ed as size '12', but the _builtin_va_arg code on x86_64 was always loading this out of registers as {double, double}. Thus, the 2nd store into the vec3f was storing in bytes 12-15! This patch alters the original implementation which always assumed {double, double} to use the actual coerced type instead, so the LLVM-IR generated is a load/GEP/store of a <2 x float> and a float, rather than a double and a double. Tests were added for all combinations I could think of that would fit in 2 FP registers, and all work exactly as expected. Differential Revision: https://reviews.llvm.org/D42811 llvm-svn: 324098
2018-02-02 23:53:35 +08:00
// CHECK: vaarg.in_reg:
// CHECK: [[Vec1D1FLoad1:%.*]] = load double, double*
// CHECK: [[Vec1D1FGEP1:%.*]] = getelementptr inbounds { double, float }, { double, float }* {{%.*}}, i32 0, i32 0
// CHECK: store double [[Vec1D1FLoad1]], double* [[Vec1D1FGEP1]]
// CHECK: [[Vec1D1FLoad2:%.*]] = load float, float*
// CHECK: [[Vec1D1FGEP2:%.*]] = getelementptr inbounds { double, float }, { double, float }* {{%.*}}, i32 0, i32 1
// CHECK: store float [[Vec1D1FLoad2]], float* [[Vec1D1FGEP2]]
// CHECK: vaarg.in_mem: