summaryrefslogtreecommitdiffstats
path: root/llvm/test/CodeGen/AArch64/neon-bitwise-instructions.ll
Commit message (Collapse)AuthorAgeFilesLines
* [AArch64] Harden test caseEvandro Menezes2018-03-051-151/+158
| | | | | | NFC llvm-svn: 326724
* [AArch64] Improve code generation of constant vectorsEvandro Menezes2018-03-051-2/+2
| | | | | | | | | | | | | Use the whole gammut of constant immediates available to set up a vector. Instead of using, for example, `mov w0, #0xffff; dup v0.4s, w0`, which transfers between register files, use the more efficient `movi v0.4s, #-1` instead. Not limited to just a few values, but any immediate value that can be encoded by all the variants of `FMOV`, `MOVI`, `MVNI`, thus eliminating the need to there be patterns to optimize special cases. Differential revision: https://reviews.llvm.org/D42133 llvm-svn: 326718
* AArch64/ARM64: move ARM64 into AArch64's placeTim Northover2014-05-241-1/+1
| | | | | | | | | | | | | | | 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
* AArch64/ARM64: remove AArch64 from tree prior to renaming ARM64.Tim Northover2014-05-241-1/+0
| | | | | | | | | | | | | | | | I'm doing this in two phases for a better "git blame" record. This commit removes the previous AArch64 backend and redirects all functionality to ARM64. It also deduplicates test-lines and removes orphaned AArch64 tests. The next step will be "git mv ARM64 AArch64" and rewire most of the tests. Hopefully LLVM is still functional, though it would be even better if no-one ever had to care because the rename happens straight afterwards. llvm-svn: 209576
* ARM64: print correct aliases for NEON mov & mvn instructionsTim Northover2014-05-151-2/+2
| | | | | | | | In all cases, if a "mov" alias exists, it is the canonical form of the instruction. Now that TableGen can support aliases containing syntax variants, we can enable them and improve the quality of the asm output. llvm-svn: 208874
* AArch64/ARM64: port BSL logic from AArch64 & enable test.Tim Northover2014-04-181-176/+344
| | | | | | | | | | | I enhanced it a little in the process. The decision shouldn't really be beased on whether a BUILD_VECTOR is a splat: any set of constants will do the job provided they're related in the correct way. Also, the BUILD_VECTOR could be any operand of the incoming AND nodes, so it's best to check for all 4 possibilities rather than assuming it'll be the RHS. llvm-svn: 206569
* Teach the DAGCombiner how to fold 'vselect' dag nodes accordingAndrea Di Biagio2014-01-081-17/+18
| | | | | | | | to the following two rules: 1) fold (vselect (build_vector AllOnes), A, B) -> A 2) fold (vselect (build_vector AllZeros), A, B) -> B llvm-svn: 198777
* [AArch64 NEON] Fixed incorrect immediate used in BIC instruction.Kevin Qin2014-01-071-17/+448
| | | | llvm-svn: 198675
* [AArch64 NEON] Fix invalid constant used in vselect condition.Kevin Qin2014-01-061-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | There is a wrong assumption that the vector element type and the type of each ConstantSDNode in the build_vector were the same. However, when promoting the integer operand of a legally typed build_vector, the operand type and the vector element type do not need to be the same (See method 'DAGTypeLegalizer::PromoteIntOp_BUILD_VECTOR' in LegalizeIntegerTypes.cpp). in AArch64 backend, the following dag sequence: C0: i1 = Constant<0> C1: i1 = Constant<-1> V: v8i1 = BUILD_VECTOR C1, C1, C0, C0, C0, C0, C0, C0 is type-legalized into: NewC0: i32 = Constant<0> NewC1: i32 = Constant<1> V: v8i8 = BUILD_VECTOR NewC1, NewC1, NewC0, NewC0, NewC0, NewC0, NewC0, NewC0 Forcing a getZeroExtend to VTBits to ensure that the new constant is correctly. llvm-svn: 198582
* Fix Incorrect CHECK message [0-31]+ in test case.Kevin Qin2013-12-121-88/+88
| | | | | | | In regular expression, [0-31]+ equals to [0-3]+, not the number from 0 to 31. So change it to [0-9]+. llvm-svn: 197113
* AArch64: add initial NEON supportTim Northover2013-08-011-0/+594
Patch by Ana Pazos. - Completed implementation of instruction formats: AdvSIMD three same AdvSIMD modified immediate AdvSIMD scalar pairwise - Completed implementation of instruction classes (some of the instructions in these classes belong to yet unfinished instruction formats): Vector Arithmetic Vector Immediate Vector Pairwise Arithmetic - Initial implementation of instruction formats: AdvSIMD scalar two-reg misc AdvSIMD scalar three same - Intial implementation of instruction class: Scalar Arithmetic - Initial clang changes to support arm v8 intrinsics. Note: no clang changes for scalar intrinsics function name mangling yet. - Comprehensive test cases for added instructions To verify auto codegen, encoding, decoding, diagnosis, intrinsics. llvm-svn: 187567
OpenPOWER on IntegriCloud