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/builtins-ppc-quadword.c

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

250 lines
10 KiB
C
Raw Normal View History

This patch adds support for the vector quadword add/sub instructions introduced in POWER8. These are the Clang-related changes for http://reviews.llvm.org/D9081 vadduqm vaddeuqm vaddcuq vaddecuq vsubuqm vsubeuqm vsubcuq vsubecuq All builtins are added in altivec.h, and guarded with the POWER8_VECTOR and powerpc64 macros. http://reviews.llvm.org/D9903 llvm-svn: 238145
2015-05-25 23:52:45 +08:00
// REQUIRES: powerpc-registered-target
Remove the -faltivec alias option and replace it with -maltivec everywhere. The alias was only ever used on darwin and had some issues there, and isn't used in practice much. Also fixes a problem with -mno-altivec not turning off -maltivec. Also add a diagnostic for faltivec/fno-altivec that directs users to use maltivec options and include the altivec.h file explicitly. llvm-svn: 298449
2017-03-22 06:06:18 +08:00
// RUN: %clang_cc1 -target-feature +altivec -target-feature +power8-vector \
This patch adds support for the vector quadword add/sub instructions introduced in POWER8. These are the Clang-related changes for http://reviews.llvm.org/D9081 vadduqm vaddeuqm vaddcuq vaddecuq vsubuqm vsubeuqm vsubcuq vsubecuq All builtins are added in altivec.h, and guarded with the POWER8_VECTOR and powerpc64 macros. http://reviews.llvm.org/D9903 llvm-svn: 238145
2015-05-25 23:52:45 +08:00
// RUN: -triple powerpc64-unknown-unknown -emit-llvm %s -o - | FileCheck %s
Remove the -faltivec alias option and replace it with -maltivec everywhere. The alias was only ever used on darwin and had some issues there, and isn't used in practice much. Also fixes a problem with -mno-altivec not turning off -maltivec. Also add a diagnostic for faltivec/fno-altivec that directs users to use maltivec options and include the altivec.h file explicitly. llvm-svn: 298449
2017-03-22 06:06:18 +08:00
// RUN: %clang_cc1 -target-feature +altivec -target-feature +power8-vector \
This patch adds support for the vector quadword add/sub instructions introduced in POWER8. These are the Clang-related changes for http://reviews.llvm.org/D9081 vadduqm vaddeuqm vaddcuq vaddecuq vsubuqm vsubeuqm vsubcuq vsubecuq All builtins are added in altivec.h, and guarded with the POWER8_VECTOR and powerpc64 macros. http://reviews.llvm.org/D9903 llvm-svn: 238145
2015-05-25 23:52:45 +08:00
// RUN: -triple powerpc64le-unknown-unknown -emit-llvm %s -o - \
// RUN: | FileCheck %s -check-prefix=CHECK-LE
Remove the -faltivec alias option and replace it with -maltivec everywhere. The alias was only ever used on darwin and had some issues there, and isn't used in practice much. Also fixes a problem with -mno-altivec not turning off -maltivec. Also add a diagnostic for faltivec/fno-altivec that directs users to use maltivec options and include the altivec.h file explicitly. llvm-svn: 298449
2017-03-22 06:06:18 +08:00
// RUN: not %clang_cc1 -target-feature +altivec -triple powerpc-unknown-unknown \
This patch adds support for the vector quadword add/sub instructions introduced in POWER8. These are the Clang-related changes for http://reviews.llvm.org/D9081 vadduqm vaddeuqm vaddcuq vaddecuq vsubuqm vsubeuqm vsubcuq vsubecuq All builtins are added in altivec.h, and guarded with the POWER8_VECTOR and powerpc64 macros. http://reviews.llvm.org/D9903 llvm-svn: 238145
2015-05-25 23:52:45 +08:00
// RUN: -emit-llvm %s -o - 2>&1 | FileCheck %s -check-prefix=CHECK-PPC
The time when -faltivec (or, on clang only, -maltivec) will magically include altivec.h has come and gone. Rationale: This causes modules, rewrite-includes, etc to be sad and people should just include altivec.h in their source. llvm-svn: 264235
2016-03-24 09:26:08 +08:00
#include <altivec.h>
This patch adds support for the vector quadword add/sub instructions introduced in POWER8. These are the Clang-related changes for http://reviews.llvm.org/D9081 vadduqm vaddeuqm vaddcuq vaddecuq vsubuqm vsubeuqm vsubcuq vsubecuq All builtins are added in altivec.h, and guarded with the POWER8_VECTOR and powerpc64 macros. http://reviews.llvm.org/D9903 llvm-svn: 238145
2015-05-25 23:52:45 +08:00
// CHECK-PPC: error: __int128 is not supported on this target
vector signed __int128 vlll = { -1 };
// CHECK-PPC: error: __int128 is not supported on this target
vector unsigned __int128 vulll = { 1 };
[PowerPC] Implement plain VSX load/store builtins. Implement all the different 24 overloads for vec_xl and vec_xst. llvm-svn: 286455
2016-11-10 22:39:56 +08:00
signed long long param_sll;
// CHECK-PPC: error: __int128 is not supported on this target
signed __int128 param_lll;
// CHECK-PPC: error: __int128 is not supported on this target
unsigned __int128 param_ulll;
This patch adds support for the vector quadword add/sub instructions introduced in POWER8. These are the Clang-related changes for http://reviews.llvm.org/D9081 vadduqm vaddeuqm vaddcuq vaddecuq vsubuqm vsubeuqm vsubcuq vsubecuq All builtins are added in altivec.h, and guarded with the POWER8_VECTOR and powerpc64 macros. http://reviews.llvm.org/D9903 llvm-svn: 238145
2015-05-25 23:52:45 +08:00
// CHECK-PPC: error: __int128 is not supported on this target
vector signed __int128 res_vlll;
// CHECK-PPC: error: __int128 is not supported on this target
vector unsigned __int128 res_vulll;
[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition Summary: Clang -fpic defaults to -fno-semantic-interposition (GCC -fpic defaults to -fsemantic-interposition). Users need to specify -fsemantic-interposition to get semantic interposition behavior. Semantic interposition is currently a best-effort feature. There may still be some cases where it is not handled well. Reviewers: peter.smith, rnk, serge-sans-paille, sfertile, jfb, jdoerfert Subscribers: dschuff, jyknight, dylanmckay, nemanjai, jvesely, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, arphaman, PkmX, jocewei, jsji, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D73865
2020-02-03 04:23:47 +08:00
// CHECK-LABEL: define dso_local void @test1
This patch adds support for the vector quadword add/sub instructions introduced in POWER8. These are the Clang-related changes for http://reviews.llvm.org/D9081 vadduqm vaddeuqm vaddcuq vaddecuq vsubuqm vsubeuqm vsubcuq vsubecuq All builtins are added in altivec.h, and guarded with the POWER8_VECTOR and powerpc64 macros. http://reviews.llvm.org/D9903 llvm-svn: 238145
2015-05-25 23:52:45 +08:00
void test1() {
/* vec_add */
res_vlll = vec_add(vlll, vlll);
// CHECK: add <1 x i128>
// CHECK-LE: add <1 x i128>
// CHECK-PPC: error: call to 'vec_add' is ambiguous
res_vulll = vec_add(vulll, vulll);
// CHECK: add <1 x i128>
// CHECK-LE: add <1 x i128>
// CHECK-PPC: error: call to 'vec_add' is ambiguous
/* vec_vadduqm */
res_vlll = vec_vadduqm(vlll, vlll);
// CHECK: add <1 x i128>
// CHECK-LE: add <1 x i128>
// CHECK-PPC: error: assigning to '__vector __int128' (vector of 1 '__int128' value) from incompatible type 'int'
res_vulll = vec_vadduqm(vulll, vulll);
// CHECK: add <1 x i128>
// CHECK-LE: add <1 x i128>
// CHECK-PPC: error: assigning to '__vector unsigned __int128' (vector of 1 'unsigned __int128' value) from incompatible type 'int'
/* vec_vaddeuqm */
res_vlll = vec_vaddeuqm(vlll, vlll, vlll);
// CHECK: @llvm.ppc.altivec.vaddeuqm
// CHECK-LE: @llvm.ppc.altivec.vaddeuqm
// CHECK-PPC: error: assigning to '__vector __int128' (vector of 1 '__int128' value) from incompatible type 'int'
res_vulll = vec_vaddeuqm(vulll, vulll, vulll);
// CHECK: @llvm.ppc.altivec.vaddeuqm
// CHECK-LE: @llvm.ppc.altivec.vaddeuqm
// CHECK-PPC: error: assigning to '__vector unsigned __int128' (vector of 1 'unsigned __int128' value) from incompatible type 'int'
/* vec_addc */
res_vlll = vec_addc(vlll, vlll);
// CHECK: @llvm.ppc.altivec.vaddcuq
// CHECK-LE: @llvm.ppc.altivec.vaddcuq
// KCHECK-PPC: error: call to 'vec_addc' is ambiguous
res_vulll = vec_addc(vulll, vulll);
// CHECK: @llvm.ppc.altivec.vaddcuq
// CHECK-LE: @llvm.ppc.altivec.vaddcuq
// KCHECK-PPC: error: call to 'vec_addc' is ambiguous
/* vec_vaddcuq */
res_vlll = vec_vaddcuq(vlll, vlll);
// CHECK: @llvm.ppc.altivec.vaddcuq
// CHECK-LE: @llvm.ppc.altivec.vaddcuq
// CHECK-PPC: error: assigning to '__vector __int128' (vector of 1 '__int128' value) from incompatible type 'int'
res_vulll = vec_vaddcuq(vulll, vulll);
// CHECK: @llvm.ppc.altivec.vaddcuq
// CHECK-LE: @llvm.ppc.altivec.vaddcuq
// CHECK-PPC: error: assigning to '__vector unsigned __int128' (vector of 1 'unsigned __int128' value) from incompatible type 'int'
/* vec_vaddecuq */
res_vlll = vec_vaddecuq(vlll, vlll, vlll);
// CHECK: @llvm.ppc.altivec.vaddecuq
// CHECK-LE: @llvm.ppc.altivec.vaddecuq
// CHECK-PPC: error: assigning to '__vector __int128' (vector of 1 '__int128' value) from incompatible type 'int'
res_vulll = vec_vaddecuq(vulll, vulll, vulll);
// CHECK: @llvm.ppc.altivec.vaddecuq
// CHECK-LE: @llvm.ppc.altivec.vaddecuq
// CHECK-PPC: error: assigning to '__vector unsigned __int128' (vector of 1 'unsigned __int128' value) from incompatible type 'int'
/* vec_sub */
res_vlll = vec_sub(vlll, vlll);
// CHECK: sub <1 x i128>
// CHECK-LE: sub <1 x i128>
// CHECK-PPC: error: call to 'vec_sub' is ambiguous
res_vulll = vec_sub(vulll, vulll);
// CHECK: sub <1 x i128>
// CHECK-LE: sub <1 x i128>
// CHECK-PPC: error: call to 'vec_sub' is ambiguous
/* vec_vsubuqm */
res_vlll = vec_vsubuqm(vlll, vlll);
// CHECK: sub <1 x i128>
// CHECK-LE: sub <1 x i128>
// CHECK-PPC: error: assigning to '__vector __int128' (vector of 1 '__int128' value) from incompatible type 'int'
res_vulll = vec_vsubuqm(vulll, vulll);
// CHECK: sub <1 x i128>
// CHECK-LE: sub <1 x i128>
// CHECK-PPC: error: assigning to '__vector unsigned __int128' (vector of 1 'unsigned __int128' value) from incompatible type 'int'
/* vec_vsubeuqm */
res_vlll = vec_vsubeuqm(vlll, vlll, vlll);
// CHECK: @llvm.ppc.altivec.vsubeuqm
// CHECK-LE: @llvm.ppc.altivec.vsubeuqm
// CHECK-PPC: error: assigning to '__vector __int128' (vector of 1 '__int128' value) from incompatible type 'int'
[PPC] support for arithmetic builtins in the FE (commit again after fixing the buildbot failures) This adds various overloads of the following builtins to altivec.h: vec_neg vec_nabs vec_adde vec_addec vec_sube vec_subec vec_subc Note that for vec_sub builtins on 32 bit integers, the semantics is similar to what ISA describes for instructions like vsubecuq that work on quadwords: the first operand is added to the one's complement of the second operand. (As opposed to two's complement which I expected). llvm-svn: 287872
2016-11-24 20:40:04 +08:00
/* vec_sube */
res_vlll = vec_sube(vlll, vlll, vlll);
// CHECK: @llvm.ppc.altivec.vsubeuqm
// CHECK-LE: @llvm.ppc.altivec.vsubeuqm
// CHECK-PPC: error: call to 'vec_sube' is ambiguous
res_vulll = vec_sube(vulll, vulll, vulll);
// CHECK: @llvm.ppc.altivec.vsubeuqm
// CHECK-LE: @llvm.ppc.altivec.vsubeuqm
// CHECK-PPC: error: call to 'vec_sube' is ambiguous
res_vlll = vec_sube(vlll, vlll, vlll);
// CHECK: @llvm.ppc.altivec.vsubeuqm
// CHECK-LE: @llvm.ppc.altivec.vsubeuqm
// CHECK-PPC: error: call to 'vec_sube' is ambiguous
This patch adds support for the vector quadword add/sub instructions introduced in POWER8. These are the Clang-related changes for http://reviews.llvm.org/D9081 vadduqm vaddeuqm vaddcuq vaddecuq vsubuqm vsubeuqm vsubcuq vsubecuq All builtins are added in altivec.h, and guarded with the POWER8_VECTOR and powerpc64 macros. http://reviews.llvm.org/D9903 llvm-svn: 238145
2015-05-25 23:52:45 +08:00
res_vulll = vec_vsubeuqm(vulll, vulll, vulll);
// CHECK: @llvm.ppc.altivec.vsubeuqm
// CHECK-LE: @llvm.ppc.altivec.vsubeuqm
// CHECK-PPC: error: assigning to '__vector unsigned __int128' (vector of 1 'unsigned __int128' value) from incompatible type 'int'
[PPC] support for arithmetic builtins in the FE (commit again after fixing the buildbot failures) This adds various overloads of the following builtins to altivec.h: vec_neg vec_nabs vec_adde vec_addec vec_sube vec_subec vec_subc Note that for vec_sub builtins on 32 bit integers, the semantics is similar to what ISA describes for instructions like vsubecuq that work on quadwords: the first operand is added to the one's complement of the second operand. (As opposed to two's complement which I expected). llvm-svn: 287872
2016-11-24 20:40:04 +08:00
res_vulll = vec_sube(vulll, vulll, vulll);
// CHECK: @llvm.ppc.altivec.vsubeuqm
// CHECK-LE: @llvm.ppc.altivec.vsubeuqm
// CHECK-PPC: error: call to 'vec_sube' is ambiguous
This patch adds support for the vector quadword add/sub instructions introduced in POWER8. These are the Clang-related changes for http://reviews.llvm.org/D9081 vadduqm vaddeuqm vaddcuq vaddecuq vsubuqm vsubeuqm vsubcuq vsubecuq All builtins are added in altivec.h, and guarded with the POWER8_VECTOR and powerpc64 macros. http://reviews.llvm.org/D9903 llvm-svn: 238145
2015-05-25 23:52:45 +08:00
/* vec_subc */
res_vlll = vec_subc(vlll, vlll);
// CHECK: @llvm.ppc.altivec.vsubcuq
// CHECK-LE: @llvm.ppc.altivec.vsubcuq
// KCHECK-PPC: error: call to 'vec_subc' is ambiguous
res_vulll = vec_subc(vulll, vulll);
// CHECK: @llvm.ppc.altivec.vsubcuq
// CHECK-LE: @llvm.ppc.altivec.vsubcuq
// KCHECK-PPC: error: call to 'vec_subc' is ambiguous
/* vec_vsubcuq */
res_vlll = vec_vsubcuq(vlll, vlll);
// CHECK: @llvm.ppc.altivec.vsubcuq
// CHECK-LE: @llvm.ppc.altivec.vsubcuq
// CHECK-PPC: error: assigning to '__vector __int128' (vector of 1 '__int128' value) from incompatible type 'int'
res_vulll = vec_vsubcuq(vulll, vulll);
// CHECK: @llvm.ppc.altivec.vsubcuq
// CHECK-LE: @llvm.ppc.altivec.vsubcuq
// CHECK-PPC: error: assigning to '__vector unsigned __int128' (vector of 1 'unsigned __int128' value) from incompatible type 'int'
/* vec_vsubecuq */
res_vlll = vec_vsubecuq(vlll, vlll, vlll);
// CHECK: @llvm.ppc.altivec.vsubecuq
// CHECK-LE: @llvm.ppc.altivec.vsubecuq
[PPC] support for arithmetic builtins in the FE (commit again after fixing the buildbot failures) This adds various overloads of the following builtins to altivec.h: vec_neg vec_nabs vec_adde vec_addec vec_sube vec_subec vec_subc Note that for vec_sub builtins on 32 bit integers, the semantics is similar to what ISA describes for instructions like vsubecuq that work on quadwords: the first operand is added to the one's complement of the second operand. (As opposed to two's complement which I expected). llvm-svn: 287872
2016-11-24 20:40:04 +08:00
// CHECK-PPC: error: assigning to '__vector __int128' (vector of 1 '__int128' value) from incompatible type 'int'
[PPC] support for arithmetic builtins in the FE (commit again after fixing the buildbot failures) This adds various overloads of the following builtins to altivec.h: vec_neg vec_nabs vec_adde vec_addec vec_sube vec_subec vec_subc Note that for vec_sub builtins on 32 bit integers, the semantics is similar to what ISA describes for instructions like vsubecuq that work on quadwords: the first operand is added to the one's complement of the second operand. (As opposed to two's complement which I expected). llvm-svn: 287795
2016-11-24 02:36:29 +08:00
[PPC] revert r287795 A test that passed locally is failing on one of the build bots. llvm-svn: 287796
2016-11-24 02:55:17 +08:00
res_vulll = vec_vsubecuq(vulll, vulll, vulll);
[PPC] support for arithmetic builtins in the FE (commit again after fixing the buildbot failures) This adds various overloads of the following builtins to altivec.h: vec_neg vec_nabs vec_adde vec_addec vec_sube vec_subec vec_subc Note that for vec_sub builtins on 32 bit integers, the semantics is similar to what ISA describes for instructions like vsubecuq that work on quadwords: the first operand is added to the one's complement of the second operand. (As opposed to two's complement which I expected). llvm-svn: 287795
2016-11-24 02:36:29 +08:00
// CHECK: @llvm.ppc.altivec.vsubecuq
// CHECK-LE: @llvm.ppc.altivec.vsubecuq
[PPC] support for arithmetic builtins in the FE (commit again after fixing the buildbot failures) This adds various overloads of the following builtins to altivec.h: vec_neg vec_nabs vec_adde vec_addec vec_sube vec_subec vec_subc Note that for vec_sub builtins on 32 bit integers, the semantics is similar to what ISA describes for instructions like vsubecuq that work on quadwords: the first operand is added to the one's complement of the second operand. (As opposed to two's complement which I expected). llvm-svn: 287872
2016-11-24 20:40:04 +08:00
// CHECK-PPC: error: assigning to '__vector unsigned __int128' (vector of 1 'unsigned __int128' value) from incompatible type 'int'
res_vlll = vec_subec(vlll, vlll, vlll);
// CHECK: @llvm.ppc.altivec.vsubecuq
// CHECK-LE: @llvm.ppc.altivec.vsubecuq
// CHECK-PPC: error: assigning to '__vector __int128' (vector of 1 '__int128' value) from incompatible type 'int'
res_vulll = vec_subec(vulll, vulll, vulll);
// CHECK: @llvm.ppc.altivec.vsubecuq
// CHECK-LE: @llvm.ppc.altivec.vsubecuq
This patch adds support for the vector quadword add/sub instructions introduced in POWER8. These are the Clang-related changes for http://reviews.llvm.org/D9081 vadduqm vaddeuqm vaddcuq vaddecuq vsubuqm vsubeuqm vsubcuq vsubecuq All builtins are added in altivec.h, and guarded with the POWER8_VECTOR and powerpc64 macros. http://reviews.llvm.org/D9903 llvm-svn: 238145
2015-05-25 23:52:45 +08:00
// CHECK-PPC: error: assigning to '__vector unsigned __int128' (vector of 1 'unsigned __int128' value) from incompatible type 'int'
[PPC] add vector byte reverse functions to altivec.h This patch corresponds to review https://reviews.llvm.org/D25915. Committing on behalf of Sean Fertile. llvm-svn: 285268
2016-10-27 14:23:57 +08:00
res_vulll = vec_revb(vulll);
// CHECK: store <16 x i8> <i8 15, i8 14, i8 13, i8 12, i8 11, i8 10, i8 9, i8 8, i8 7, i8 6, i8 5, i8 4, i8 3, i8 2, i8 1, i8 0>, <16 x i8>* {{%.+}}, align 16
// CHECK: call <4 x i32> @llvm.ppc.altivec.vperm(<4 x i32> {{%.+}}, <4 x i32> {{%.+}}, <16 x i8> {{%.+}})
// CHECK-LE: store <16 x i8> <i8 15, i8 14, i8 13, i8 12, i8 11, i8 10, i8 9, i8 8, i8 7, i8 6, i8 5, i8 4, i8 3, i8 2, i8 1, i8 0>, <16 x i8>* {{%.+}}, align 16
// CHECK-LE: store <16 x i8> <i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1>, <16 x i8>* {{%.+}}, align 16
// CHECK-LE: xor <16 x i8>
// CHECK-LE: call <4 x i32> @llvm.ppc.altivec.vperm(<4 x i32> {{%.+}}, <4 x i32> {{%.+}}, <16 x i8> {{%.+}})
// CHECK_PPC: error: call to 'vec_revb' is ambiguous
[PowerPC] Implement plain VSX load/store builtins. Implement all the different 24 overloads for vec_xl and vec_xst. llvm-svn: 286455
2016-11-10 22:39:56 +08:00
/* vec_xl */
res_vlll = vec_xl(param_sll, &param_lll);
[PowerPC] Vector load/store builtins overstate alignment of pointers A number of builtins in altivec.h load/store vectors from pointers to scalar types. Currently they just cast the pointer to a vector pointer, but expressions like that have the alignment of the target type. Of course, the input pointer did not have that alignment so this triggers UBSan (and rightly so). This resolves https://bugs.llvm.org/show_bug.cgi?id=39704 Differential revision: https://reviews.llvm.org/D54787 llvm-svn: 347556
2018-11-26 22:35:38 +08:00
// CHECK: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 1
// CHECK-LE: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 1
[PowerPC] Implement plain VSX load/store builtins. Implement all the different 24 overloads for vec_xl and vec_xst. llvm-svn: 286455
2016-11-10 22:39:56 +08:00
// CHECK-PPC: error: call to 'vec_xl' is ambiguous
res_vulll = vec_xl(param_sll, &param_ulll);
[PowerPC] Vector load/store builtins overstate alignment of pointers A number of builtins in altivec.h load/store vectors from pointers to scalar types. Currently they just cast the pointer to a vector pointer, but expressions like that have the alignment of the target type. Of course, the input pointer did not have that alignment so this triggers UBSan (and rightly so). This resolves https://bugs.llvm.org/show_bug.cgi?id=39704 Differential revision: https://reviews.llvm.org/D54787 llvm-svn: 347556
2018-11-26 22:35:38 +08:00
// CHECK: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 1
// CHECK-LE: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 1
[PowerPC] Implement plain VSX load/store builtins. Implement all the different 24 overloads for vec_xl and vec_xst. llvm-svn: 286455
2016-11-10 22:39:56 +08:00
// CHECK-PPC: error: call to 'vec_xl' is ambiguous
/* vec_xst */
vec_xst(vlll, param_sll, &param_lll);
[PowerPC] Vector load/store builtins overstate alignment of pointers A number of builtins in altivec.h load/store vectors from pointers to scalar types. Currently they just cast the pointer to a vector pointer, but expressions like that have the alignment of the target type. Of course, the input pointer did not have that alignment so this triggers UBSan (and rightly so). This resolves https://bugs.llvm.org/show_bug.cgi?id=39704 Differential revision: https://reviews.llvm.org/D54787 llvm-svn: 347556
2018-11-26 22:35:38 +08:00
// CHECK: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 1
// CHECK-LE: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 1
[PowerPC] Implement plain VSX load/store builtins. Implement all the different 24 overloads for vec_xl and vec_xst. llvm-svn: 286455
2016-11-10 22:39:56 +08:00
// CHECK-PPC: error: call to 'vec_xst' is ambiguous
vec_xst(vulll, param_sll, &param_ulll);
[PowerPC] Vector load/store builtins overstate alignment of pointers A number of builtins in altivec.h load/store vectors from pointers to scalar types. Currently they just cast the pointer to a vector pointer, but expressions like that have the alignment of the target type. Of course, the input pointer did not have that alignment so this triggers UBSan (and rightly so). This resolves https://bugs.llvm.org/show_bug.cgi?id=39704 Differential revision: https://reviews.llvm.org/D54787 llvm-svn: 347556
2018-11-26 22:35:38 +08:00
// CHECK: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 1
// CHECK-LE: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 1
[PowerPC] Implement plain VSX load/store builtins. Implement all the different 24 overloads for vec_xl and vec_xst. llvm-svn: 286455
2016-11-10 22:39:56 +08:00
// CHECK-PPC: error: call to 'vec_xst' is ambiguous
[PowerPC] Implement BE VSX load/store builtins - clang portion. This patch implements all the overloads for vec_xl_be and vec_xst_be. On BE, they behaves exactly the same with vec_xl and vec_xst, therefore they are simply implemented by defining a matching macro. On LE, they are implemented by defining new builtins and intrinsics. For int/float/long long/double, it is just a load (lxvw4x/lxvd2x) or store(stxvw4x/stxvd2x). For char/char/short, we also need some extra shuffling before or after call the builtins to get the desired BE order. For int128, simply call vec_xl or vec_xst. llvm-svn: 286971
2016-11-15 22:30:56 +08:00
/* vec_xl_be */
res_vlll = vec_xl_be(param_sll, &param_lll);
[PowerPC] Vector load/store builtins overstate alignment of pointers A number of builtins in altivec.h load/store vectors from pointers to scalar types. Currently they just cast the pointer to a vector pointer, but expressions like that have the alignment of the target type. Of course, the input pointer did not have that alignment so this triggers UBSan (and rightly so). This resolves https://bugs.llvm.org/show_bug.cgi?id=39704 Differential revision: https://reviews.llvm.org/D54787 llvm-svn: 347556
2018-11-26 22:35:38 +08:00
// CHECK: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 1
// CHECK-LE: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 1
[PowerPC] Implement BE VSX load/store builtins - clang portion. This patch implements all the overloads for vec_xl_be and vec_xst_be. On BE, they behaves exactly the same with vec_xl and vec_xst, therefore they are simply implemented by defining a matching macro. On LE, they are implemented by defining new builtins and intrinsics. For int/float/long long/double, it is just a load (lxvw4x/lxvd2x) or store(stxvw4x/stxvd2x). For char/char/short, we also need some extra shuffling before or after call the builtins to get the desired BE order. For int128, simply call vec_xl or vec_xst. llvm-svn: 286971
2016-11-15 22:30:56 +08:00
// CHECK-PPC: error: call to 'vec_xl' is ambiguous
res_vulll = vec_xl_be(param_sll, &param_ulll);
[PowerPC] Vector load/store builtins overstate alignment of pointers A number of builtins in altivec.h load/store vectors from pointers to scalar types. Currently they just cast the pointer to a vector pointer, but expressions like that have the alignment of the target type. Of course, the input pointer did not have that alignment so this triggers UBSan (and rightly so). This resolves https://bugs.llvm.org/show_bug.cgi?id=39704 Differential revision: https://reviews.llvm.org/D54787 llvm-svn: 347556
2018-11-26 22:35:38 +08:00
// CHECK: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 1
// CHECK-LE: load <1 x i128>, <1 x i128>* %{{[0-9]+}}, align 1
[PowerPC] Implement BE VSX load/store builtins - clang portion. This patch implements all the overloads for vec_xl_be and vec_xst_be. On BE, they behaves exactly the same with vec_xl and vec_xst, therefore they are simply implemented by defining a matching macro. On LE, they are implemented by defining new builtins and intrinsics. For int/float/long long/double, it is just a load (lxvw4x/lxvd2x) or store(stxvw4x/stxvd2x). For char/char/short, we also need some extra shuffling before or after call the builtins to get the desired BE order. For int128, simply call vec_xl or vec_xst. llvm-svn: 286971
2016-11-15 22:30:56 +08:00
// CHECK-PPC: error: call to 'vec_xl' is ambiguous
/* vec_xst_be */
vec_xst_be(vlll, param_sll, &param_lll);
[PowerPC] Vector load/store builtins overstate alignment of pointers A number of builtins in altivec.h load/store vectors from pointers to scalar types. Currently they just cast the pointer to a vector pointer, but expressions like that have the alignment of the target type. Of course, the input pointer did not have that alignment so this triggers UBSan (and rightly so). This resolves https://bugs.llvm.org/show_bug.cgi?id=39704 Differential revision: https://reviews.llvm.org/D54787 llvm-svn: 347556
2018-11-26 22:35:38 +08:00
// CHECK: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 1
// CHECK-LE: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 1
[PowerPC] Implement BE VSX load/store builtins - clang portion. This patch implements all the overloads for vec_xl_be and vec_xst_be. On BE, they behaves exactly the same with vec_xl and vec_xst, therefore they are simply implemented by defining a matching macro. On LE, they are implemented by defining new builtins and intrinsics. For int/float/long long/double, it is just a load (lxvw4x/lxvd2x) or store(stxvw4x/stxvd2x). For char/char/short, we also need some extra shuffling before or after call the builtins to get the desired BE order. For int128, simply call vec_xl or vec_xst. llvm-svn: 286971
2016-11-15 22:30:56 +08:00
// CHECK-PPC: error: call to 'vec_xst' is ambiguous
vec_xst_be(vulll, param_sll, &param_ulll);
[PowerPC] Vector load/store builtins overstate alignment of pointers A number of builtins in altivec.h load/store vectors from pointers to scalar types. Currently they just cast the pointer to a vector pointer, but expressions like that have the alignment of the target type. Of course, the input pointer did not have that alignment so this triggers UBSan (and rightly so). This resolves https://bugs.llvm.org/show_bug.cgi?id=39704 Differential revision: https://reviews.llvm.org/D54787 llvm-svn: 347556
2018-11-26 22:35:38 +08:00
// CHECK: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 1
// CHECK-LE: store <1 x i128> %{{[0-9]+}}, <1 x i128>* %{{[0-9]+}}, align 1
[PowerPC] Implement BE VSX load/store builtins - clang portion. This patch implements all the overloads for vec_xl_be and vec_xst_be. On BE, they behaves exactly the same with vec_xl and vec_xst, therefore they are simply implemented by defining a matching macro. On LE, they are implemented by defining new builtins and intrinsics. For int/float/long long/double, it is just a load (lxvw4x/lxvd2x) or store(stxvw4x/stxvd2x). For char/char/short, we also need some extra shuffling before or after call the builtins to get the desired BE order. For int128, simply call vec_xl or vec_xst. llvm-svn: 286971
2016-11-15 22:30:56 +08:00
// CHECK-PPC: error: call to 'vec_xst' is ambiguous
This patch adds support for the vector quadword add/sub instructions introduced in POWER8. These are the Clang-related changes for http://reviews.llvm.org/D9081 vadduqm vaddeuqm vaddcuq vaddecuq vsubuqm vsubeuqm vsubcuq vsubecuq All builtins are added in altivec.h, and guarded with the POWER8_VECTOR and powerpc64 macros. http://reviews.llvm.org/D9903 llvm-svn: 238145
2015-05-25 23:52:45 +08:00
}