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

155 lines
6.9 KiB
ArmAsm
Raw Normal View History

[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: not llvm-mc -triple=thumbv7 -show-encoding < %s 2>&1 | FileCheck --check-prefix=CHECK --check-prefix=CHECK-NONARM --check-prefix=CHECK-THUMBV7 %s
// RUN: not llvm-mc -triple=thumbv8 -show-encoding < %s 2>&1 | FileCheck --check-prefix=CHECK --check-prefix=CHECK-NONARM --check-prefix=CHECK-THUMBV8 %s
// 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.
// Using PC is invalid in thumb
lsl pc, r0, #0
lsl r0, pc, #0
lsl pc, pc, #0
lsls pc, r0, #0
lsls r0, pc, #0
lsls pc, pc, #0
// CHECK-NONARM: error: instruction requires: arm-mode
// CHECK-NONARM-NEXT: lsl pc, r0, #0
// CHECK-NONARM: error: instruction requires: arm-mode
// CHECK-NONARM-NEXT: lsl r0, pc, #0
// CHECK-NONARM: error: instruction requires: arm-mode
// CHECK-NONARM-NEXT: lsl pc, pc, #0
// CHECK-NONARM: error: instruction requires: arm-mode
// CHECK-NONARM-NEXT: lsls pc, r0, #0
// CHECK-NONARM: error: instruction requires: arm-mode
// CHECK-NONARM-NEXT: lsls r0, pc, #0
// CHECK-NONARM: error: instruction requires: arm-mode
// CHECK-NONARM-NEXT: lsls pc, pc, #0
// CHECK-ARM: mov pc, r0 @ encoding: [0x00,0xf0,0xa0,0xe1]
// CHECK-ARM: mov r0, pc @ encoding: [0x0f,0x00,0xa0,0xe1]
// CHECK-ARM: mov pc, pc @ encoding: [0x0f,0xf0,0xa0,0xe1]
// CHECK-ARM: movs pc, r0 @ encoding: [0x00,0xf0,0xb0,0xe1]
// CHECK-ARM: movs r0, pc @ encoding: [0x0f,0x00,0xb0,0xe1]
// CHECK-ARM: movs pc, pc @ encoding: [0x0f,0xf0,0xb0,0xe1]
mov pc, r0, lsl #0
mov r0, pc, lsl #0
mov pc, pc, lsl #0
movs pc, r0, lsl #0
movs r0, pc, lsl #0
movs pc, pc, lsl #0
// FIXME: Really the error we should be giving is "requires: arm-mode"
// CHECK-NONARM: error: invalid operand for instruction
// CHECK-NONARM-NEXT: mov pc, r0, lsl #0
// CHECK-NONARM: error: invalid operand for instruction
// CHECK-NONARM-NEXT: mov r0, pc, lsl #0
// CHECK-NONARM: error: invalid operand for instruction
// CHECK-NONARM-NEXT: mov pc, pc, lsl #0
// CHECK-NONARM: error: invalid operand for instruction
// CHECK-NONARM-NEXT: movs pc, r0, lsl #0
// CHECK-NONARM: error: invalid operand for instruction
// CHECK-NONARM-NEXT: movs r0, pc, lsl #0
// CHECK-NONARM: error: invalid operand for instruction
// CHECK-NONARM-NEXT: movs pc, pc, lsl #0
// CHECK-ARM: mov pc, r0 @ encoding: [0x00,0xf0,0xa0,0xe1]
// CHECK-ARM: mov r0, pc @ encoding: [0x0f,0x00,0xa0,0xe1]
// CHECK-ARM: mov pc, pc @ encoding: [0x0f,0xf0,0xa0,0xe1]
// CHECK-ARM: movs pc, r0 @ encoding: [0x00,0xf0,0xb0,0xe1]
// CHECK-ARM: movs r0, pc @ encoding: [0x0f,0x00,0xb0,0xe1]
// CHECK-ARM: movs pc, pc @ encoding: [0x0f,0xf0,0xb0,0xe1]
// Using SP is invalid before ARMv8 in thumb unless non-flags-setting
// and one of the source and destination is not SP
lsl sp, sp, #0
lsls sp, sp, #0
lsls r0, sp, #0
lsls sp, r0, #0
// CHECK-THUMBV7: error: instruction variant requires ARMv8 or later
// CHECK-THUMBV7-NEXT: lsl sp, sp, #0
// CHECK-THUMBV7: error: instruction variant requires ARMv8 or later
// CHECK-THUMBV7-NEXT: lsls sp, sp, #0
// CHECK-THUMBV7: error: instruction variant requires ARMv8 or later
// CHECK-THUMBV7-NEXT: lsls r0, sp, #0
// CHECK-THUMBV7: error: instruction variant requires ARMv8 or later
// CHECK-THUMBV7-NEXT: lsls sp, r0, #0
// CHECK-ARM: mov sp, sp @ encoding: [0x0d,0xd0,0xa0,0xe1]
// CHECK-ARM: movs sp, sp @ encoding: [0x0d,0xd0,0xb0,0xe1]
// CHECK-ARM: movs r0, sp @ encoding: [0x0d,0x00,0xb0,0xe1]
// CHECK-ARM: movs sp, r0 @ encoding: [0x00,0xd0,0xb0,0xe1]
mov sp, sp, lsl #0
movs sp, sp, lsl #0
movs r0, sp, lsl #0
movs sp, r0, lsl #0
// FIXME: We should consistently have the "requires ARMv8" error here
// CHECK-THUMBV7: error: invalid operand for instruction
// CHECK-THUMBV7-NEXT: mov sp, sp, lsl #0
// CHECK-THUMBV7: error: invalid operand for instruction
// CHECK-THUMBV7-NEXT: movs sp, sp, lsl #0
// CHECK-THUMBV7: error: instruction variant requires ARMv8 or later
// CHECK-THUMBV7-NEXT: movs r0, sp, lsl #0
// CHECK-THUMBV7: error: invalid operand for instruction
// CHECK-THUMBV7-NEXT: movs sp, r0, lsl #0
// CHECK-ARM: mov sp, sp @ encoding: [0x0d,0xd0,0xa0,0xe1]
// CHECK-ARM: movs sp, sp @ encoding: [0x0d,0xd0,0xb0,0xe1]
// CHECK-ARM: movs r0, sp @ encoding: [0x0d,0x00,0xb0,0xe1]
// CHECK-ARM: movs sp, r0 @ encoding: [0x00,0xd0,0xb0,0xe1]
// 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]