summaryrefslogtreecommitdiff
path: root/test/CodeGen/ARM/fast-isel-vararg.ll
diff options
context:
space:
mode:
authorJuergen Ributzka <juergen@apple.com>2014-08-13 22:08:02 +0000
committerJuergen Ributzka <juergen@apple.com>2014-08-13 22:08:02 +0000
commiteb1c51f8b393b2377f886502a35d2665770f7363 (patch)
tree5650e7e3d8334c2ac1872f3f15812a4ecb1bf13c /test/CodeGen/ARM/fast-isel-vararg.ll
parent220504496854df2aa8e738ad998b100992292e11 (diff)
[FastISel] Let the target decide first if it wants to materialize a constant.
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>. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215588 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'test/CodeGen/ARM/fast-isel-vararg.ll')
-rw-r--r--test/CodeGen/ARM/fast-isel-vararg.ll1
1 files changed, 0 insertions, 1 deletions
diff --git a/test/CodeGen/ARM/fast-isel-vararg.ll b/test/CodeGen/ARM/fast-isel-vararg.ll
index 0b7b0bd1c6f..3ff2b151ab5 100644
--- a/test/CodeGen/ARM/fast-isel-vararg.ll
+++ b/test/CodeGen/ARM/fast-isel-vararg.ll
@@ -29,7 +29,6 @@ entry:
; ARM: bl {{_?CallVariadic}}
; THUMB: sub sp, #32
; THUMB: movs r0, #5
-; THUMB: movt r0, #0
; THUMB: ldr r1, [sp, #28]
; THUMB: ldr r2, [sp, #24]
; THUMB: ldr r3, [sp, #20]