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/Thumb/bic_imm.ll

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

116 lines
3.0 KiB
LLVM
Raw Normal View History

[ARM] Testcase for missed optimization for masking. When the result of masking is truncated to i16, we should try to use "bic" instead of "and". llvm-svn: 335001
2018-06-19 08:08:32 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
[Thumb] Reapply r272251 with a fix for PR28348 (mk 2) The important thing I was missing was ensuring newly added constants were kept in topological order. Repositioning the node is correct if the constant is newly added (so it has no topological ordering) but wrong if it already existed - positioning it next in the worklist would break the topological ordering. Original commit message: [Thumb] Select a BIC instead of AND if the immediate can be encoded more optimally negated If an immediate is only used in an AND node, it is possible that the immediate can be more optimally materialized when negated. If this is the case, we can negate the immediate and use a BIC instead; int i(int a) { return a & 0xfffffeec; } Used to produce: ldr r1, [CONSTPOOL] ands r0, r1 CONSTPOOL: 0xfffffeec And now produces: movs r1, #255 adds r1, #20 ; Less costly immediate generation bics r0, r1 llvm-svn: 274543
2016-07-05 20:37:13 +08:00
; RUN: llc < %s -mtriple=thumbv7-linux-gnueabi -mcpu=cortex-m0 -verify-machineinstrs | FileCheck --check-prefix CHECK-T1 %s
; RUN: llc < %s -mtriple=thumbv7-linux-gnueabi -mcpu=cortex-m3 -verify-machineinstrs | FileCheck --check-prefix CHECK-T2 %s
define i32 @i(i32 %a) {
[ARM] Testcase for missed optimization for masking. When the result of masking is truncated to i16, we should try to use "bic" instead of "and". llvm-svn: 335001
2018-06-19 08:08:32 +08:00
; CHECK-T1-LABEL: i:
; CHECK-T1: @ %bb.0: @ %entry
; CHECK-T1-NEXT: movs r1, #255
; CHECK-T1-NEXT: adds r1, #20
; CHECK-T1-NEXT: bics r0, r1
; CHECK-T1-NEXT: bx lr
;
; CHECK-T2-LABEL: i:
; CHECK-T2: @ %bb.0: @ %entry
; CHECK-T2-NEXT: movw r1, #275
; CHECK-T2-NEXT: bics r0, r1
; CHECK-T2-NEXT: bx lr
[Thumb] Reapply r272251 with a fix for PR28348 (mk 2) The important thing I was missing was ensuring newly added constants were kept in topological order. Repositioning the node is correct if the constant is newly added (so it has no topological ordering) but wrong if it already existed - positioning it next in the worklist would break the topological ordering. Original commit message: [Thumb] Select a BIC instead of AND if the immediate can be encoded more optimally negated If an immediate is only used in an AND node, it is possible that the immediate can be more optimally materialized when negated. If this is the case, we can negate the immediate and use a BIC instead; int i(int a) { return a & 0xfffffeec; } Used to produce: ldr r1, [CONSTPOOL] ands r0, r1 CONSTPOOL: 0xfffffeec And now produces: movs r1, #255 adds r1, #20 ; Less costly immediate generation bics r0, r1 llvm-svn: 274543
2016-07-05 20:37:13 +08:00
entry:
%and = and i32 %a, -276
ret i32 %and
}
define i32 @j(i32 %a) {
[ARM] Testcase for missed optimization for masking. When the result of masking is truncated to i16, we should try to use "bic" instead of "and". llvm-svn: 335001
2018-06-19 08:08:32 +08:00
; CHECK-T1-LABEL: j:
; CHECK-T1: @ %bb.0: @ %entry
; CHECK-T1-NEXT: movs r1, #128
; CHECK-T1-NEXT: bics r0, r1
; CHECK-T1-NEXT: bx lr
;
; CHECK-T2-LABEL: j:
; CHECK-T2: @ %bb.0: @ %entry
; CHECK-T2-NEXT: bic r0, r0, #128
; CHECK-T2-NEXT: bx lr
[Thumb] Reapply r272251 with a fix for PR28348 (mk 2) The important thing I was missing was ensuring newly added constants were kept in topological order. Repositioning the node is correct if the constant is newly added (so it has no topological ordering) but wrong if it already existed - positioning it next in the worklist would break the topological ordering. Original commit message: [Thumb] Select a BIC instead of AND if the immediate can be encoded more optimally negated If an immediate is only used in an AND node, it is possible that the immediate can be more optimally materialized when negated. If this is the case, we can negate the immediate and use a BIC instead; int i(int a) { return a & 0xfffffeec; } Used to produce: ldr r1, [CONSTPOOL] ands r0, r1 CONSTPOOL: 0xfffffeec And now produces: movs r1, #255 adds r1, #20 ; Less costly immediate generation bics r0, r1 llvm-svn: 274543
2016-07-05 20:37:13 +08:00
entry:
%and = and i32 %a, -129
ret i32 %and
}
[ARM] Testcase for missed optimization for masking. When the result of masking is truncated to i16, we should try to use "bic" instead of "and". llvm-svn: 335001
2018-06-19 08:08:32 +08:00
define void @truncated(i16 %a, i16* %p) {
; CHECK-T1-LABEL: truncated:
; CHECK-T1: @ %bb.0:
[ARM] Adjust AND immediates to make them cheaper to select. LLVM normally prefers to minimize the number of bits set in an AND immediate, but that doesn't always match the available ARM instructions. In Thumb1 mode, prefer uxtb or uxth where possible; otherwise, prefer a two-instruction sequence movs+ands or movs+bics. Some potential improvements outlined in ARMTargetLowering::targetShrinkDemandedConstant, but seems to work pretty well already. The ARMISelDAGToDAG fix ensures we don't generate an invalid UBFX instruction due to a larger-than-expected mask. (It's orthogonal, in some sense, but as far as I can tell it's either impossible or nearly impossible to reproduce the bug without this change.) According to my testing, this seems to consistently improve codesize by a small amount by forming bic more often for ISD::AND with an immediate. Differential Revision: https://reviews.llvm.org/D50030 llvm-svn: 339472
2018-08-11 05:21:53 +08:00
; CHECK-T1-NEXT: movs r2, #128
; CHECK-T1-NEXT: bics r0, r2
; CHECK-T1-NEXT: strh r0, [r1]
; CHECK-T1-NEXT: bx lr
;
; CHECK-T2-LABEL: truncated:
; CHECK-T2: @ %bb.0:
; CHECK-T2-NEXT: bic r0, r0, #128
; CHECK-T2-NEXT: strh r0, [r1]
; CHECK-T2-NEXT: bx lr
%and = and i16 %a, -129
store i16 %and, i16* %p
ret void
}
define void @truncated_neg2(i16 %a, i16* %p) {
; CHECK-T1-LABEL: truncated_neg2:
; CHECK-T1: @ %bb.0:
; CHECK-T1-NEXT: movs r2, #1
; CHECK-T1-NEXT: bics r0, r2
; CHECK-T1-NEXT: strh r0, [r1]
; CHECK-T1-NEXT: bx lr
;
; CHECK-T2-LABEL: truncated_neg2:
; CHECK-T2: @ %bb.0:
; CHECK-T2-NEXT: bic r0, r0, #1
; CHECK-T2-NEXT: strh r0, [r1]
; CHECK-T2-NEXT: bx lr
%and = and i16 %a, -2
store i16 %and, i16* %p
ret void
}
define void @truncated_neg256(i16 %a, i16* %p) {
; CHECK-T1-LABEL: truncated_neg256:
; CHECK-T1: @ %bb.0:
; CHECK-T1-NEXT: movs r2, #255
; CHECK-T1-NEXT: bics r0, r2
; CHECK-T1-NEXT: strh r0, [r1]
; CHECK-T1-NEXT: bx lr
;
; CHECK-T2-LABEL: truncated_neg256:
; CHECK-T2: @ %bb.0:
; CHECK-T2-NEXT: bic r0, r0, #255
; CHECK-T2-NEXT: strh r0, [r1]
; CHECK-T2-NEXT: bx lr
%and = and i16 %a, -256
store i16 %and, i16* %p
ret void
}
; FIXME: Thumb2 supports "bic r0, r0, #510"
define void @truncated_neg511(i16 %a, i16* %p) {
; CHECK-T1-LABEL: truncated_neg511:
; CHECK-T1: @ %bb.0:
; CHECK-T1-NEXT: ldr r2, .LCPI5_0
[ARM] Testcase for missed optimization for masking. When the result of masking is truncated to i16, we should try to use "bic" instead of "and". llvm-svn: 335001
2018-06-19 08:08:32 +08:00
; CHECK-T1-NEXT: ands r2, r0
; CHECK-T1-NEXT: strh r2, [r1]
; CHECK-T1-NEXT: bx lr
; CHECK-T1-NEXT: .p2align 2
; CHECK-T1-NEXT: @ %bb.1:
[ARM] Adjust AND immediates to make them cheaper to select. LLVM normally prefers to minimize the number of bits set in an AND immediate, but that doesn't always match the available ARM instructions. In Thumb1 mode, prefer uxtb or uxth where possible; otherwise, prefer a two-instruction sequence movs+ands or movs+bics. Some potential improvements outlined in ARMTargetLowering::targetShrinkDemandedConstant, but seems to work pretty well already. The ARMISelDAGToDAG fix ensures we don't generate an invalid UBFX instruction due to a larger-than-expected mask. (It's orthogonal, in some sense, but as far as I can tell it's either impossible or nearly impossible to reproduce the bug without this change.) According to my testing, this seems to consistently improve codesize by a small amount by forming bic more often for ISD::AND with an immediate. Differential Revision: https://reviews.llvm.org/D50030 llvm-svn: 339472
2018-08-11 05:21:53 +08:00
; CHECK-T1-NEXT: .LCPI5_0:
; CHECK-T1-NEXT: .long 65025 @ 0xfe01
[ARM] Testcase for missed optimization for masking. When the result of masking is truncated to i16, we should try to use "bic" instead of "and". llvm-svn: 335001
2018-06-19 08:08:32 +08:00
;
[ARM] Adjust AND immediates to make them cheaper to select. LLVM normally prefers to minimize the number of bits set in an AND immediate, but that doesn't always match the available ARM instructions. In Thumb1 mode, prefer uxtb or uxth where possible; otherwise, prefer a two-instruction sequence movs+ands or movs+bics. Some potential improvements outlined in ARMTargetLowering::targetShrinkDemandedConstant, but seems to work pretty well already. The ARMISelDAGToDAG fix ensures we don't generate an invalid UBFX instruction due to a larger-than-expected mask. (It's orthogonal, in some sense, but as far as I can tell it's either impossible or nearly impossible to reproduce the bug without this change.) According to my testing, this seems to consistently improve codesize by a small amount by forming bic more often for ISD::AND with an immediate. Differential Revision: https://reviews.llvm.org/D50030 llvm-svn: 339472
2018-08-11 05:21:53 +08:00
; CHECK-T2-LABEL: truncated_neg511:
[ARM] Testcase for missed optimization for masking. When the result of masking is truncated to i16, we should try to use "bic" instead of "and". llvm-svn: 335001
2018-06-19 08:08:32 +08:00
; CHECK-T2: @ %bb.0:
[ARM] Adjust AND immediates to make them cheaper to select. LLVM normally prefers to minimize the number of bits set in an AND immediate, but that doesn't always match the available ARM instructions. In Thumb1 mode, prefer uxtb or uxth where possible; otherwise, prefer a two-instruction sequence movs+ands or movs+bics. Some potential improvements outlined in ARMTargetLowering::targetShrinkDemandedConstant, but seems to work pretty well already. The ARMISelDAGToDAG fix ensures we don't generate an invalid UBFX instruction due to a larger-than-expected mask. (It's orthogonal, in some sense, but as far as I can tell it's either impossible or nearly impossible to reproduce the bug without this change.) According to my testing, this seems to consistently improve codesize by a small amount by forming bic more often for ISD::AND with an immediate. Differential Revision: https://reviews.llvm.org/D50030 llvm-svn: 339472
2018-08-11 05:21:53 +08:00
; CHECK-T2-NEXT: movw r2, #65025
[ARM] Testcase for missed optimization for masking. When the result of masking is truncated to i16, we should try to use "bic" instead of "and". llvm-svn: 335001
2018-06-19 08:08:32 +08:00
; CHECK-T2-NEXT: ands r0, r2
; CHECK-T2-NEXT: strh r0, [r1]
; CHECK-T2-NEXT: bx lr
[ARM] Adjust AND immediates to make them cheaper to select. LLVM normally prefers to minimize the number of bits set in an AND immediate, but that doesn't always match the available ARM instructions. In Thumb1 mode, prefer uxtb or uxth where possible; otherwise, prefer a two-instruction sequence movs+ands or movs+bics. Some potential improvements outlined in ARMTargetLowering::targetShrinkDemandedConstant, but seems to work pretty well already. The ARMISelDAGToDAG fix ensures we don't generate an invalid UBFX instruction due to a larger-than-expected mask. (It's orthogonal, in some sense, but as far as I can tell it's either impossible or nearly impossible to reproduce the bug without this change.) According to my testing, this seems to consistently improve codesize by a small amount by forming bic more often for ISD::AND with an immediate. Differential Revision: https://reviews.llvm.org/D50030 llvm-svn: 339472
2018-08-11 05:21:53 +08:00
%and = and i16 %a, -511
[ARM] Testcase for missed optimization for masking. When the result of masking is truncated to i16, we should try to use "bic" instead of "and". llvm-svn: 335001
2018-06-19 08:08:32 +08:00
store i16 %and, i16* %p
ret void
}