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/ARM/fast-isel-mvn.ll

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

94 lines
2.3 KiB
LLVM
Raw Normal View History

[ARM] Define a subtarget feature that is used to avoid using movt/movw pairs for 32-bit immediates. This change is needed to avoid emitting movt/movw pairs when doing LTO and do so on a per-function basis. Out-of-tree projects currently using cl::opt option -arm-use-movt=0 or false to avoid emitting movt/movw pairs should make changes to add subtarget feature "+no-movt" (see the changes made to clang in r242368). rdar://problem/21529937 Differential Revision: http://reviews.llvm.org/D11026 llvm-svn: 242369
2015-07-16 08:58:23 +08:00
; RUN: llc -O0 -verify-machineinstrs -fast-isel-abort=1 -relocation-model=dynamic-no-pic -mattr=+no-movt -mtriple=armv7-apple-ios < %s | FileCheck %s --check-prefix=CHECK --check-prefix=ARM
; RUN: llc -O0 -verify-machineinstrs -fast-isel-abort=1 -relocation-model=dynamic-no-pic -mattr=+no-movt -mtriple=armv7-linux-gnueabi < %s | FileCheck %s --check-prefix=CHECK --check-prefix=ARM
; RUN: llc -O0 -verify-machineinstrs -fast-isel-abort=1 -relocation-model=dynamic-no-pic -mattr=+no-movt -mtriple=thumbv7-apple-ios < %s | FileCheck %s --check-prefix=CHECK --check-prefix=ARM
; RUN: llc -O0 -verify-machineinstrs -fast-isel-abort=1 -relocation-model=dynamic-no-pic -mtriple=thumbv7-apple-ios < %s | FileCheck %s --check-prefix=CHECK --check-prefix=THUMB
; RUN: llc -O0 -verify-machineinstrs -fast-isel-abort=1 -relocation-model=dynamic-no-pic -mtriple=armv7-apple-ios < %s | FileCheck %s --check-prefix=MOVT
Add support for using MVN to materialize negative constants. rdar://10412592 llvm-svn: 144348
2011-11-11 08:36:21 +08:00
; rdar://10412592
define void @t1() nounwind {
entry:
Reapply [FastISel] Let the target decide first if it wants to materialize a constant (215588). Note: This was originally reverted to track down a buildbot error. This commit exposed a latent bug that was fixed in r215753. Therefore it is reapplied without any modifications. I run it through SPEC2k and SPEC2k6 for AArch64 and it didn't introduce any new regeressions. Original commit message: This changes the order in which FastISel tries to materialize a constant. Originally it would try to use a simple target-independent approach, which can lead to the generation of inefficient code. On X86 this would result in the use of movabsq to materialize any 64bit integer constant - even for simple and small values such as 0 and 1. Also some very funny floating-point materialization could be observed too. On AArch64 it would materialize the constant 0 in a register even the architecture has an actual "zero" register. On ARM it would generate unnecessary mov instructions or not use mvn. This change simply changes the order and always asks the target first if it likes to materialize the constant. This doesn't fix all the issues mentioned above, but it enables the targets to implement such optimizations. Related to <rdar://problem/17420988>. llvm-svn: 216006
2014-08-20 03:05:24 +08:00
; CHECK-LABEL: t1
; CHECK: mvn r0, #0
Add support for using MVN to materialize negative constants. rdar://10412592 llvm-svn: 144348
2011-11-11 08:36:21 +08:00
call void @foo(i32 -1)
ret void
}
declare void @foo(i32)
define void @t2() nounwind {
entry:
Reapply [FastISel] Let the target decide first if it wants to materialize a constant (215588). Note: This was originally reverted to track down a buildbot error. This commit exposed a latent bug that was fixed in r215753. Therefore it is reapplied without any modifications. I run it through SPEC2k and SPEC2k6 for AArch64 and it didn't introduce any new regeressions. Original commit message: This changes the order in which FastISel tries to materialize a constant. Originally it would try to use a simple target-independent approach, which can lead to the generation of inefficient code. On X86 this would result in the use of movabsq to materialize any 64bit integer constant - even for simple and small values such as 0 and 1. Also some very funny floating-point materialization could be observed too. On AArch64 it would materialize the constant 0 in a register even the architecture has an actual "zero" register. On ARM it would generate unnecessary mov instructions or not use mvn. This change simply changes the order and always asks the target first if it likes to materialize the constant. This doesn't fix all the issues mentioned above, but it enables the targets to implement such optimizations. Related to <rdar://problem/17420988>. llvm-svn: 216006
2014-08-20 03:05:24 +08:00
; CHECK-LABEL: t2
; CHECK: mvn r0, #233
Add support for using MVN to materialize negative constants. rdar://10412592 llvm-svn: 144348
2011-11-11 08:36:21 +08:00
call void @foo(i32 -234)
ret void
}
define void @t3() nounwind {
entry:
Reapply [FastISel] Let the target decide first if it wants to materialize a constant (215588). Note: This was originally reverted to track down a buildbot error. This commit exposed a latent bug that was fixed in r215753. Therefore it is reapplied without any modifications. I run it through SPEC2k and SPEC2k6 for AArch64 and it didn't introduce any new regeressions. Original commit message: This changes the order in which FastISel tries to materialize a constant. Originally it would try to use a simple target-independent approach, which can lead to the generation of inefficient code. On X86 this would result in the use of movabsq to materialize any 64bit integer constant - even for simple and small values such as 0 and 1. Also some very funny floating-point materialization could be observed too. On AArch64 it would materialize the constant 0 in a register even the architecture has an actual "zero" register. On ARM it would generate unnecessary mov instructions or not use mvn. This change simply changes the order and always asks the target first if it likes to materialize the constant. This doesn't fix all the issues mentioned above, but it enables the targets to implement such optimizations. Related to <rdar://problem/17420988>. llvm-svn: 216006
2014-08-20 03:05:24 +08:00
; CHECK-LABEL: t3
; CHECK: mvn r0, #256
Add support for using MVN to materialize negative constants. rdar://10412592 llvm-svn: 144348
2011-11-11 08:36:21 +08:00
call void @foo(i32 -257)
ret void
}
; Load from constant pool
define void @t4() nounwind {
entry:
Reapply [FastISel] Let the target decide first if it wants to materialize a constant (215588). Note: This was originally reverted to track down a buildbot error. This commit exposed a latent bug that was fixed in r215753. Therefore it is reapplied without any modifications. I run it through SPEC2k and SPEC2k6 for AArch64 and it didn't introduce any new regeressions. Original commit message: This changes the order in which FastISel tries to materialize a constant. Originally it would try to use a simple target-independent approach, which can lead to the generation of inefficient code. On X86 this would result in the use of movabsq to materialize any 64bit integer constant - even for simple and small values such as 0 and 1. Also some very funny floating-point materialization could be observed too. On AArch64 it would materialize the constant 0 in a register even the architecture has an actual "zero" register. On ARM it would generate unnecessary mov instructions or not use mvn. This change simply changes the order and always asks the target first if it likes to materialize the constant. This doesn't fix all the issues mentioned above, but it enables the targets to implement such optimizations. Related to <rdar://problem/17420988>. llvm-svn: 216006
2014-08-20 03:05:24 +08:00
; ARM-LABEL: t4
; ARM: ldr r0
; THUMB-LABEL: t4
; THUMB: movw r0, #65278
; THUMB: movt r0, #65535
Add support for using MVN to materialize negative constants. rdar://10412592 llvm-svn: 144348
2011-11-11 08:36:21 +08:00
call void @foo(i32 -258)
ret void
}
define void @t5() nounwind {
entry:
Reapply [FastISel] Let the target decide first if it wants to materialize a constant (215588). Note: This was originally reverted to track down a buildbot error. This commit exposed a latent bug that was fixed in r215753. Therefore it is reapplied without any modifications. I run it through SPEC2k and SPEC2k6 for AArch64 and it didn't introduce any new regeressions. Original commit message: This changes the order in which FastISel tries to materialize a constant. Originally it would try to use a simple target-independent approach, which can lead to the generation of inefficient code. On X86 this would result in the use of movabsq to materialize any 64bit integer constant - even for simple and small values such as 0 and 1. Also some very funny floating-point materialization could be observed too. On AArch64 it would materialize the constant 0 in a register even the architecture has an actual "zero" register. On ARM it would generate unnecessary mov instructions or not use mvn. This change simply changes the order and always asks the target first if it likes to materialize the constant. This doesn't fix all the issues mentioned above, but it enables the targets to implement such optimizations. Related to <rdar://problem/17420988>. llvm-svn: 216006
2014-08-20 03:05:24 +08:00
; CHECK-LABEL: t5
; CHECK: mvn r0, #65280
Add support for using MVN to materialize negative constants. rdar://10412592 llvm-svn: 144348
2011-11-11 08:36:21 +08:00
call void @foo(i32 -65281)
ret void
}
define void @t6() nounwind {
entry:
Reapply [FastISel] Let the target decide first if it wants to materialize a constant (215588). Note: This was originally reverted to track down a buildbot error. This commit exposed a latent bug that was fixed in r215753. Therefore it is reapplied without any modifications. I run it through SPEC2k and SPEC2k6 for AArch64 and it didn't introduce any new regeressions. Original commit message: This changes the order in which FastISel tries to materialize a constant. Originally it would try to use a simple target-independent approach, which can lead to the generation of inefficient code. On X86 this would result in the use of movabsq to materialize any 64bit integer constant - even for simple and small values such as 0 and 1. Also some very funny floating-point materialization could be observed too. On AArch64 it would materialize the constant 0 in a register even the architecture has an actual "zero" register. On ARM it would generate unnecessary mov instructions or not use mvn. This change simply changes the order and always asks the target first if it likes to materialize the constant. This doesn't fix all the issues mentioned above, but it enables the targets to implement such optimizations. Related to <rdar://problem/17420988>. llvm-svn: 216006
2014-08-20 03:05:24 +08:00
; CHECK-LABEL: t6
; CHECK: mvn r0, #978944
Add support for using MVN to materialize negative constants. rdar://10412592 llvm-svn: 144348
2011-11-11 08:36:21 +08:00
call void @foo(i32 -978945)
ret void
}
define void @t7() nounwind {
entry:
Reapply [FastISel] Let the target decide first if it wants to materialize a constant (215588). Note: This was originally reverted to track down a buildbot error. This commit exposed a latent bug that was fixed in r215753. Therefore it is reapplied without any modifications. I run it through SPEC2k and SPEC2k6 for AArch64 and it didn't introduce any new regeressions. Original commit message: This changes the order in which FastISel tries to materialize a constant. Originally it would try to use a simple target-independent approach, which can lead to the generation of inefficient code. On X86 this would result in the use of movabsq to materialize any 64bit integer constant - even for simple and small values such as 0 and 1. Also some very funny floating-point materialization could be observed too. On AArch64 it would materialize the constant 0 in a register even the architecture has an actual "zero" register. On ARM it would generate unnecessary mov instructions or not use mvn. This change simply changes the order and always asks the target first if it likes to materialize the constant. This doesn't fix all the issues mentioned above, but it enables the targets to implement such optimizations. Related to <rdar://problem/17420988>. llvm-svn: 216006
2014-08-20 03:05:24 +08:00
; CHECK-LABEL: t7
; CHECK: mvn r0, #267386880
Add support for using MVN to materialize negative constants. rdar://10412592 llvm-svn: 144348
2011-11-11 08:36:21 +08:00
call void @foo(i32 -267386881)
ret void
}
define void @t8() nounwind {
entry:
Reapply [FastISel] Let the target decide first if it wants to materialize a constant (215588). Note: This was originally reverted to track down a buildbot error. This commit exposed a latent bug that was fixed in r215753. Therefore it is reapplied without any modifications. I run it through SPEC2k and SPEC2k6 for AArch64 and it didn't introduce any new regeressions. Original commit message: This changes the order in which FastISel tries to materialize a constant. Originally it would try to use a simple target-independent approach, which can lead to the generation of inefficient code. On X86 this would result in the use of movabsq to materialize any 64bit integer constant - even for simple and small values such as 0 and 1. Also some very funny floating-point materialization could be observed too. On AArch64 it would materialize the constant 0 in a register even the architecture has an actual "zero" register. On ARM it would generate unnecessary mov instructions or not use mvn. This change simply changes the order and always asks the target first if it likes to materialize the constant. This doesn't fix all the issues mentioned above, but it enables the targets to implement such optimizations. Related to <rdar://problem/17420988>. llvm-svn: 216006
2014-08-20 03:05:24 +08:00
; CHECK-LABEL: t8
; CHECK: mvn r0, #65280
Add support for using MVN to materialize negative constants. rdar://10412592 llvm-svn: 144348
2011-11-11 08:36:21 +08:00
call void @foo(i32 -65281)
ret void
}
define void @t9() nounwind {
entry:
Reapply [FastISel] Let the target decide first if it wants to materialize a constant (215588). Note: This was originally reverted to track down a buildbot error. This commit exposed a latent bug that was fixed in r215753. Therefore it is reapplied without any modifications. I run it through SPEC2k and SPEC2k6 for AArch64 and it didn't introduce any new regeressions. Original commit message: This changes the order in which FastISel tries to materialize a constant. Originally it would try to use a simple target-independent approach, which can lead to the generation of inefficient code. On X86 this would result in the use of movabsq to materialize any 64bit integer constant - even for simple and small values such as 0 and 1. Also some very funny floating-point materialization could be observed too. On AArch64 it would materialize the constant 0 in a register even the architecture has an actual "zero" register. On ARM it would generate unnecessary mov instructions or not use mvn. This change simply changes the order and always asks the target first if it likes to materialize the constant. This doesn't fix all the issues mentioned above, but it enables the targets to implement such optimizations. Related to <rdar://problem/17420988>. llvm-svn: 216006
2014-08-20 03:05:24 +08:00
; CHECK-LABEL: t9
; CHECK: mvn r0, #2130706432
Add support for using MVN to materialize negative constants. rdar://10412592 llvm-svn: 144348
2011-11-11 08:36:21 +08:00
call void @foo(i32 -2130706433)
ret void
ARM target code clean up. Check for iOS, not Darwin where it makes sense. llvm-svn: 146981
2011-12-21 02:26:50 +08:00
}
[FastISel][ARM] Fall-back to constant pool loads when materializing an i32 constant. FastEmit_i won't always succeed to materialize an i32 constant and just fail. This would trigger a fall-back to SelectionDAG, which is really not necessary. This fix will first fall-back to a constant pool load to materialize the constant before giving up for good. This fixes <rdar://problem/18022633>. llvm-svn: 215682
2014-08-15 07:29:49 +08:00
; Load from constant pool.
define i32 @t10(i32 %a) {
[FastISel][ARM] Fix unit test from r215682. Thanks Jim for finding this. llvm-svn: 215733
2014-08-16 01:23:20 +08:00
; MOVT-LABEL: t10
; MOVT: ldr
[FastISel][ARM] Fall-back to constant pool loads when materializing an i32 constant. FastEmit_i won't always succeed to materialize an i32 constant and just fail. This would trigger a fall-back to SelectionDAG, which is really not necessary. This fix will first fall-back to a constant pool load to materialize the constant before giving up for good. This fixes <rdar://problem/18022633>. llvm-svn: 215682
2014-08-15 07:29:49 +08:00
%1 = xor i32 -1998730207, %a
ret i32 %1
}