mirror of
https://github.com/RPCSX/llvm.git
synced 2024-12-13 23:18:51 +00:00
14cceb3342
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274543 91177308-0d34-0410-b5e6-96231b3b80d8
17 lines
476 B
LLVM
17 lines
476 B
LLVM
; RUN: llc < %s | FileCheck %s
|
|
|
|
target datalayout = "e-m:e-p:32:32-i1:8:32-i8:8:32-i16:16:32-i64:64-v128:64:128-a:0:32-n32-S64"
|
|
target triple = "thumbv7--linux-gnueabihf"
|
|
|
|
; CHECK-LABEL: f:
|
|
; CHECK: bic
|
|
define void @f(i32* nocapture %b, i32* nocapture %c, i32 %a) {
|
|
%1 = and i32 %a, -4096
|
|
store i32 %1, i32* %c, align 4
|
|
%2 = and i32 %a, 4095
|
|
%3 = or i32 %2, 4096
|
|
%4 = load i32, i32* %b, align 4
|
|
%5 = add nsw i32 %4, %3
|
|
store i32 %5, i32* %b, align 4
|
|
ret void
|
|
} |