[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
This commit is contained in:
Juergen Ributzka
2014-08-13 22:08:02 +00:00
parent 2205044968
commit eb1c51f8b3
10 changed files with 56 additions and 87 deletions

View File

@@ -57,11 +57,11 @@ entry:
; ELF64: t10
%call = call i32 @bar(i8 zeroext 0, i8 zeroext -8, i8 zeroext -69, i8 zeroext 28, i8 zeroext 40, i8 zeroext -70)
; ELF64: li 3, 0
; ELF64: li 4, 248
; ELF64: li 5, 187
; ELF64: li 4, -8
; ELF64: li 5, -69
; ELF64: li 6, 28
; ELF64: li 7, 40
; ELF64: li 8, 186
; ELF64: li 8, -70
; ELF64: rldicl 3, 3, 0, 56
; ELF64: rldicl 4, 4, 0, 56
; ELF64: rldicl 5, 5, 0, 56