maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/AArch64/arm64-vector-ext.ll

28 lines
720 B
LLVM
Raw Normal View History

AArch64/ARM64: move ARM64 into AArch64's place This commit starts with a "git mv ARM64 AArch64" and continues out from there, renaming the C++ classes, intrinsics, and other target-local objects for consistency. "ARM64" test directories are also moved, and tests that began their life in ARM64 use an arm64 triple, those from AArch64 use an aarch64 triple. Both should be equivalent though. This finishes the AArch64 merge, and everyone should feel free to continue committing as normal now. llvm-svn: 209577
2014-05-24 20:50:23 +08:00
; RUN: llc < %s -march=arm64 -aarch64-neon-syntax=apple | FileCheck %s
ARM64: initial backend import This adds a second implementation of the AArch64 architecture to LLVM, accessible in parallel via the "arm64" triple. The plan over the coming weeks & months is to merge the two into a single backend, during which time thorough code review should naturally occur. Everything will be easier with the target in-tree though, hence this commit. llvm-svn: 205090
2014-03-29 18:18:08 +08:00
;CHECK: @func30
;CHECK: ushll.4s v0, v0, #0
ARM64: hexify printing various immediate operands This is mostly aimed at the NEON logical operations and MOVI/MVNI (since they accept weird shifts which are more naturally understandable in hex notation). Also changes BRK/HINT etc, which is probably a neutral change, but easier than the alternative. llvm-svn: 207634
2014-04-30 19:19:28 +08:00
;CHECK: movi.4s v1, #0x1
ARM64: initial backend import This adds a second implementation of the AArch64 architecture to LLVM, accessible in parallel via the "arm64" triple. The plan over the coming weeks & months is to merge the two into a single backend, during which time thorough code review should naturally occur. Everything will be easier with the target in-tree though, hence this commit. llvm-svn: 205090
2014-03-29 18:18:08 +08:00
;CHECK: and.16b v0, v0, v1
;CHECK: str q0, [x0]
;CHECK: ret
%T0_30 = type <4 x i1>
%T1_30 = type <4 x i32>
define void @func30(%T0_30 %v0, %T1_30* %p1) {
%r = zext %T0_30 %v0 to %T1_30
store %T1_30 %r, %T1_30* %p1
ret void
}
AArch64: More correctly constrain target vector extend lowering. The AArch64 target lowering for [zs]ext of vectors is set up to handle input simple types and expects the generic SDag path to do something reasonable with anything that's not a simple type. The code, however, was only checking that the result type was a simple type and assuming that implied that the source type would also be a simple type. That's not a valid assumption, as operations like "zext <1 x i1> %0 to <1 x i32>" demonstrate. The fix is to simply explicitly validate the source type as well as the result type. PR20791 llvm-svn: 216689
2014-08-29 06:08:28 +08:00
; Extend from v1i1 was crashing things (PR20791). Make sure we do something
; sensible instead.
define <1 x i32> @autogen_SD7918() {
; CHECK-LABEL: autogen_SD7918
; CHECK: movi d0, #0000000000000000
; CHECK-NEXT: ret
%I29 = insertelement <1 x i1> zeroinitializer, i1 false, i32 0
%ZE = zext <1 x i1> %I29 to <1 x i32>
ret <1 x i32> %ZE
}