maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/MC/ARM/lsl-zero.s

58 lines
2.6 KiB
ArmAsm
Raw Normal View History

[ARM] Split up lsl-zero test into two tests On Windows stderr and stdout happen to get interleaved in a way that causes the test to fail, so split it up into a test that checks for errors and a test that doesn't. llvm-svn: 297273
2017-03-08 20:49:18 +08:00
// RUN: llvm-mc -triple=thumbv7 -show-encoding < %s 2>&1 | FileCheck --check-prefix=CHECK --check-prefix=CHECK-NONARM --check-prefix=CHECK-THUMBV7 %s
// RUN: llvm-mc -triple=thumbv8 -show-encoding < %s 2>&1 | FileCheck --check-prefix=CHECK --check-prefix=CHECK-NONARM --check-prefix=CHECK-THUMBV8 %s
[ARM] LSL #0 is an alias of MOV Currently we handle this correctly in arm, but in thumb we don't which leads to an unpredictable instruction being emitted for LSL #0 in an IT block and SP not being permitted in some cases when it should be. For the thumb2 LSL we can handle this by making LSL #0 an alias of MOV in the .td file, but for thumb1 we need to handle it in checkTargetMatchPredicate to get the IT handling right. We also need to adjust the handling of MOV rd, rn, LSL #0 to avoid generating the 16-bit encoding in an IT block. We should also adjust it to allow SP in the same way that it is allowed in MOV rd, rn, but I haven't done that here because it looks like it would take quite a lot of work to get right. Additionally correct the selection of the 16-bit shift instructions in processInstruction, where it was checking if the two registers were equal when it should have been checking if they were low. It appears that previously this code was never executed and the 16-bit encoding was selected by default, but the other changes I've done here have somehow made it start being used. Differential Revision: https://reviews.llvm.org/D30294 llvm-svn: 296342
2017-02-27 22:40:51 +08:00
// RUN: llvm-mc -triple=armv7 -show-encoding < %s 2>&1 | FileCheck --check-prefix=CHECK --check-prefix=CHECK-ARM %s
// lsl #0 is actually mov, so here we check that it behaves the same as
// mov with regards to the permitted registers and how it behaves in an
// IT block.
// Non-flags-setting with only one of source and destination SP should
// be OK
lsl sp, r0, #0
lsl r0, sp, #0
// CHECK-NONARM: mov.w sp, r0 @ encoding: [0x4f,0xea,0x00,0x0d]
// CHECK-NONARM: mov.w r0, sp @ encoding: [0x4f,0xea,0x0d,0x00]
// CHECK-ARM: mov sp, r0 @ encoding: [0x00,0xd0,0xa0,0xe1]
// CHECK-ARM: mov r0, sp @ encoding: [0x0d,0x00,0xa0,0xe1]
//FIXME: pre-ARMv8 we give an error for these instructions
//mov sp, r0, lsl #0
//mov r0, sp, lsl #0
// LSL #0 in IT block should select the 32-bit encoding
itt eq
lsleq r0, r1, #0
lslseq r0, r1, #0
[ARM] Correct handling of LSL #0 in an IT block The check for LSL #0 in an IT block was checking if operand 4 was zero, but operand 4 is the condition code operand so it was actually checking for LSLEQ. Fix this by checking operand 3, which really is the immediate operand, and add some tests. Differential Revision: https://reviews.llvm.org/D30692 llvm-svn: 297142
2017-03-07 22:42:03 +08:00
itt gt
lslgt r0, r1, #0
lslsgt r0, r1, #0
[ARM] LSL #0 is an alias of MOV Currently we handle this correctly in arm, but in thumb we don't which leads to an unpredictable instruction being emitted for LSL #0 in an IT block and SP not being permitted in some cases when it should be. For the thumb2 LSL we can handle this by making LSL #0 an alias of MOV in the .td file, but for thumb1 we need to handle it in checkTargetMatchPredicate to get the IT handling right. We also need to adjust the handling of MOV rd, rn, LSL #0 to avoid generating the 16-bit encoding in an IT block. We should also adjust it to allow SP in the same way that it is allowed in MOV rd, rn, but I haven't done that here because it looks like it would take quite a lot of work to get right. Additionally correct the selection of the 16-bit shift instructions in processInstruction, where it was checking if the two registers were equal when it should have been checking if they were low. It appears that previously this code was never executed and the 16-bit encoding was selected by default, but the other changes I've done here have somehow made it start being used. Differential Revision: https://reviews.llvm.org/D30294 llvm-svn: 296342
2017-02-27 22:40:51 +08:00
// CHECK-NONARM: moveq.w r0, r1 @ encoding: [0x4f,0xea,0x01,0x00]
// CHECK-NONARM: movseq.w r0, r1 @ encoding: [0x5f,0xea,0x01,0x00]
[ARM] Correct handling of LSL #0 in an IT block The check for LSL #0 in an IT block was checking if operand 4 was zero, but operand 4 is the condition code operand so it was actually checking for LSLEQ. Fix this by checking operand 3, which really is the immediate operand, and add some tests. Differential Revision: https://reviews.llvm.org/D30692 llvm-svn: 297142
2017-03-07 22:42:03 +08:00
// CHECK-NONARM: movgt.w r0, r1 @ encoding: [0x4f,0xea,0x01,0x00]
// CHECK-NONARM: movsgt.w r0, r1 @ encoding: [0x5f,0xea,0x01,0x00]
[ARM] LSL #0 is an alias of MOV Currently we handle this correctly in arm, but in thumb we don't which leads to an unpredictable instruction being emitted for LSL #0 in an IT block and SP not being permitted in some cases when it should be. For the thumb2 LSL we can handle this by making LSL #0 an alias of MOV in the .td file, but for thumb1 we need to handle it in checkTargetMatchPredicate to get the IT handling right. We also need to adjust the handling of MOV rd, rn, LSL #0 to avoid generating the 16-bit encoding in an IT block. We should also adjust it to allow SP in the same way that it is allowed in MOV rd, rn, but I haven't done that here because it looks like it would take quite a lot of work to get right. Additionally correct the selection of the 16-bit shift instructions in processInstruction, where it was checking if the two registers were equal when it should have been checking if they were low. It appears that previously this code was never executed and the 16-bit encoding was selected by default, but the other changes I've done here have somehow made it start being used. Differential Revision: https://reviews.llvm.org/D30294 llvm-svn: 296342
2017-02-27 22:40:51 +08:00
// CHECK-ARM: moveq r0, r1 @ encoding: [0x01,0x00,0xa0,0x01]
// CHECK-ARM: movseq r0, r1 @ encoding: [0x01,0x00,0xb0,0x01]
[ARM] Correct handling of LSL #0 in an IT block The check for LSL #0 in an IT block was checking if operand 4 was zero, but operand 4 is the condition code operand so it was actually checking for LSLEQ. Fix this by checking operand 3, which really is the immediate operand, and add some tests. Differential Revision: https://reviews.llvm.org/D30692 llvm-svn: 297142
2017-03-07 22:42:03 +08:00
// CHECK-ARM: movgt r0, r1 @ encoding: [0x01,0x00,0xa0,0xc1]
// CHECK-ARM: movsgt r0, r1 @ encoding: [0x01,0x00,0xb0,0xc1]
[ARM] LSL #0 is an alias of MOV Currently we handle this correctly in arm, but in thumb we don't which leads to an unpredictable instruction being emitted for LSL #0 in an IT block and SP not being permitted in some cases when it should be. For the thumb2 LSL we can handle this by making LSL #0 an alias of MOV in the .td file, but for thumb1 we need to handle it in checkTargetMatchPredicate to get the IT handling right. We also need to adjust the handling of MOV rd, rn, LSL #0 to avoid generating the 16-bit encoding in an IT block. We should also adjust it to allow SP in the same way that it is allowed in MOV rd, rn, but I haven't done that here because it looks like it would take quite a lot of work to get right. Additionally correct the selection of the 16-bit shift instructions in processInstruction, where it was checking if the two registers were equal when it should have been checking if they were low. It appears that previously this code was never executed and the 16-bit encoding was selected by default, but the other changes I've done here have somehow made it start being used. Differential Revision: https://reviews.llvm.org/D30294 llvm-svn: 296342
2017-02-27 22:40:51 +08:00
itt eq
moveq r0, r1, lsl #0
movseq r0, r1, lsl #0
[ARM] Correct handling of LSL #0 in an IT block The check for LSL #0 in an IT block was checking if operand 4 was zero, but operand 4 is the condition code operand so it was actually checking for LSLEQ. Fix this by checking operand 3, which really is the immediate operand, and add some tests. Differential Revision: https://reviews.llvm.org/D30692 llvm-svn: 297142
2017-03-07 22:42:03 +08:00
itt gt
movgt r0, r1, lsl #0
movsgt r0, r1, lsl #0
[ARM] LSL #0 is an alias of MOV Currently we handle this correctly in arm, but in thumb we don't which leads to an unpredictable instruction being emitted for LSL #0 in an IT block and SP not being permitted in some cases when it should be. For the thumb2 LSL we can handle this by making LSL #0 an alias of MOV in the .td file, but for thumb1 we need to handle it in checkTargetMatchPredicate to get the IT handling right. We also need to adjust the handling of MOV rd, rn, LSL #0 to avoid generating the 16-bit encoding in an IT block. We should also adjust it to allow SP in the same way that it is allowed in MOV rd, rn, but I haven't done that here because it looks like it would take quite a lot of work to get right. Additionally correct the selection of the 16-bit shift instructions in processInstruction, where it was checking if the two registers were equal when it should have been checking if they were low. It appears that previously this code was never executed and the 16-bit encoding was selected by default, but the other changes I've done here have somehow made it start being used. Differential Revision: https://reviews.llvm.org/D30294 llvm-svn: 296342
2017-02-27 22:40:51 +08:00
// CHECK-NONARM: moveq.w r0, r1 @ encoding: [0x4f,0xea,0x01,0x00]
// CHECK-NONARM: movseq.w r0, r1 @ encoding: [0x5f,0xea,0x01,0x00]
[ARM] Correct handling of LSL #0 in an IT block The check for LSL #0 in an IT block was checking if operand 4 was zero, but operand 4 is the condition code operand so it was actually checking for LSLEQ. Fix this by checking operand 3, which really is the immediate operand, and add some tests. Differential Revision: https://reviews.llvm.org/D30692 llvm-svn: 297142
2017-03-07 22:42:03 +08:00
// CHECK-NONARM: movgt.w r0, r1 @ encoding: [0x4f,0xea,0x01,0x00]
// CHECK-NONARM: movsgt.w r0, r1 @ encoding: [0x5f,0xea,0x01,0x00]
[ARM] LSL #0 is an alias of MOV Currently we handle this correctly in arm, but in thumb we don't which leads to an unpredictable instruction being emitted for LSL #0 in an IT block and SP not being permitted in some cases when it should be. For the thumb2 LSL we can handle this by making LSL #0 an alias of MOV in the .td file, but for thumb1 we need to handle it in checkTargetMatchPredicate to get the IT handling right. We also need to adjust the handling of MOV rd, rn, LSL #0 to avoid generating the 16-bit encoding in an IT block. We should also adjust it to allow SP in the same way that it is allowed in MOV rd, rn, but I haven't done that here because it looks like it would take quite a lot of work to get right. Additionally correct the selection of the 16-bit shift instructions in processInstruction, where it was checking if the two registers were equal when it should have been checking if they were low. It appears that previously this code was never executed and the 16-bit encoding was selected by default, but the other changes I've done here have somehow made it start being used. Differential Revision: https://reviews.llvm.org/D30294 llvm-svn: 296342
2017-02-27 22:40:51 +08:00
// CHECK-ARM: moveq r0, r1 @ encoding: [0x01,0x00,0xa0,0x01]
// CHECK-ARM: movseq r0, r1 @ encoding: [0x01,0x00,0xb0,0x01]
[ARM] Correct handling of LSL #0 in an IT block The check for LSL #0 in an IT block was checking if operand 4 was zero, but operand 4 is the condition code operand so it was actually checking for LSLEQ. Fix this by checking operand 3, which really is the immediate operand, and add some tests. Differential Revision: https://reviews.llvm.org/D30692 llvm-svn: 297142
2017-03-07 22:42:03 +08:00
// CHECK-ARM: movgt r0, r1 @ encoding: [0x01,0x00,0xa0,0xc1]
// CHECK-ARM: movsgt r0, r1 @ encoding: [0x01,0x00,0xb0,0xc1]