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/PowerPC/memcmp.ll

71 lines
2.3 KiB
LLVM
Raw Normal View History

[PowerPC] auto-generate check lines; NFC The existing check lines were more flexible, but these are small enough tests that there shouldn't be much question about register allocation. I've been hand-modifying this file as I change the CGP memcmp expansion, but that's more error-prone and time-consuming than just running the update script. llvm-svn: 306861
2017-07-01 03:20:54 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
[PPC] Inline expansion of memcmp This patch does an inline expansion of memcmp. It changes the memcmp library call into an inline expansion when the size is known at compile time and is under a target specified threshold. This expansion is implemented in CodeGenPrepare and expands into straight line code. The target specifies a maximum load size and the expansion works by using this size to load the two sources, compare, and exit early if a difference is found. It also has a special case when the memcmp result is used in a compare to zero equality. Differential Revision: https://reviews.llvm.org/D28637 llvm-svn: 304313
2017-06-01 01:12:38 +08:00
; RUN: llc -verify-machineinstrs -mcpu=pwr8 -mtriple=powerpc64le-unknown-gnu-linux < %s | FileCheck %s -check-prefix=CHECK
[PowerPC] auto-generate check lines; NFC The existing check lines were more flexible, but these are small enough tests that there shouldn't be much question about register allocation. I've been hand-modifying this file as I change the CGP memcmp expansion, but that's more error-prone and time-consuming than just running the update script. llvm-svn: 306861
2017-07-01 03:20:54 +08:00
define signext i32 @memcmp8(i32* nocapture readonly %buffer1, i32* nocapture readonly %buffer2) {
; CHECK-LABEL: memcmp8:
; CHECK: # BB#0:
; CHECK-NEXT: ldbrx 3, 0, 3
; CHECK-NEXT: ldbrx 4, 0, 4
Follow-up to r319434 to turn the pass on by default Now that the patch has gone through the buildbot cycle, turn it on by default. llvm-svn: 319535
2017-12-01 20:02:59 +08:00
; CHECK-NEXT: subfc 5, 3, 4
; CHECK-NEXT: subfe 5, 4, 4
; CHECK-NEXT: subfc 4, 4, 3
; CHECK-NEXT: subfe 3, 3, 3
; CHECK-NEXT: neg 4, 5
; CHECK-NEXT: neg 3, 3
[CGP] use subtract or subtract-of-cmps for result of memcmp expansion As noted in the code comment, transforming this in the other direction might require a separate transform here in CGP given the block-at-a-time DAG constraint. Besides that theoretical motivation, there are 2 practical motivations for the subtract-of-cmps form: 1. The codegen for both x86 and PPC is better for this IR (though PPC could be better still). There is discussion about canonicalizing IR to the select form ( http://lists.llvm.org/pipermail/llvm-dev/2017-July/114885.html ), so we probably need to add DAG transforms for those patterns anyway, but this improves the memcmp output without waiting for that step. 2. If we allow vector-sized chunks for the load and compare, x86 is better prepared to convert that to optimal code when using subtract-of-cmps, so another prerequisite patch is avoided if we choose to enable that. Differential Revision: https://reviews.llvm.org/D34904 llvm-svn: 309597
2017-08-01 02:08:24 +08:00
; CHECK-NEXT: subf 3, 3, 4
; CHECK-NEXT: extsw 3, 3
[PowerPC] auto-generate check lines; NFC The existing check lines were more flexible, but these are small enough tests that there shouldn't be much question about register allocation. I've been hand-modifying this file as I change the CGP memcmp expansion, but that's more error-prone and time-consuming than just running the update script. llvm-svn: 306861
2017-07-01 03:20:54 +08:00
; CHECK-NEXT: blr
%t0 = bitcast i32* %buffer1 to i8*
%t1 = bitcast i32* %buffer2 to i8*
%call = tail call signext i32 @memcmp(i8* %t0, i8* %t1, i64 8)
[PPC] Inline expansion of memcmp This patch does an inline expansion of memcmp. It changes the memcmp library call into an inline expansion when the size is known at compile time and is under a target specified threshold. This expansion is implemented in CodeGenPrepare and expands into straight line code. The target specifies a maximum load size and the expansion works by using this size to load the two sources, compare, and exit early if a difference is found. It also has a special case when the memcmp result is used in a compare to zero equality. Differential Revision: https://reviews.llvm.org/D28637 llvm-svn: 304313
2017-06-01 01:12:38 +08:00
ret i32 %call
}
[PowerPC] auto-generate check lines; NFC The existing check lines were more flexible, but these are small enough tests that there shouldn't be much question about register allocation. I've been hand-modifying this file as I change the CGP memcmp expansion, but that's more error-prone and time-consuming than just running the update script. llvm-svn: 306861
2017-07-01 03:20:54 +08:00
define signext i32 @memcmp4(i32* nocapture readonly %buffer1, i32* nocapture readonly %buffer2) {
; CHECK-LABEL: memcmp4:
; CHECK: # BB#0:
; CHECK-NEXT: lwbrx 3, 0, 3
; CHECK-NEXT: lwbrx 4, 0, 4
[CGP] use subtract or subtract-of-cmps for result of memcmp expansion As noted in the code comment, transforming this in the other direction might require a separate transform here in CGP given the block-at-a-time DAG constraint. Besides that theoretical motivation, there are 2 practical motivations for the subtract-of-cmps form: 1. The codegen for both x86 and PPC is better for this IR (though PPC could be better still). There is discussion about canonicalizing IR to the select form ( http://lists.llvm.org/pipermail/llvm-dev/2017-July/114885.html ), so we probably need to add DAG transforms for those patterns anyway, but this improves the memcmp output without waiting for that step. 2. If we allow vector-sized chunks for the load and compare, x86 is better prepared to convert that to optimal code when using subtract-of-cmps, so another prerequisite patch is avoided if we choose to enable that. Differential Revision: https://reviews.llvm.org/D34904 llvm-svn: 309597
2017-08-01 02:08:24 +08:00
; CHECK-NEXT: sub 5, 4, 3
; CHECK-NEXT: sub 3, 3, 4
; CHECK-NEXT: rldicl 4, 5, 1, 63
; CHECK-NEXT: rldicl 3, 3, 1, 63
; CHECK-NEXT: subf 3, 3, 4
; CHECK-NEXT: extsw 3, 3
[PowerPC] auto-generate check lines; NFC The existing check lines were more flexible, but these are small enough tests that there shouldn't be much question about register allocation. I've been hand-modifying this file as I change the CGP memcmp expansion, but that's more error-prone and time-consuming than just running the update script. llvm-svn: 306861
2017-07-01 03:20:54 +08:00
; CHECK-NEXT: blr
%t0 = bitcast i32* %buffer1 to i8*
%t1 = bitcast i32* %buffer2 to i8*
%call = tail call signext i32 @memcmp(i8* %t0, i8* %t1, i64 4)
[PPC] Inline expansion of memcmp This patch does an inline expansion of memcmp. It changes the memcmp library call into an inline expansion when the size is known at compile time and is under a target specified threshold. This expansion is implemented in CodeGenPrepare and expands into straight line code. The target specifies a maximum load size and the expansion works by using this size to load the two sources, compare, and exit early if a difference is found. It also has a special case when the memcmp result is used in a compare to zero equality. Differential Revision: https://reviews.llvm.org/D28637 llvm-svn: 304313
2017-06-01 01:12:38 +08:00
ret i32 %call
}
[PowerPC] auto-generate check lines; NFC The existing check lines were more flexible, but these are small enough tests that there shouldn't be much question about register allocation. I've been hand-modifying this file as I change the CGP memcmp expansion, but that's more error-prone and time-consuming than just running the update script. llvm-svn: 306861
2017-07-01 03:20:54 +08:00
define signext i32 @memcmp2(i32* nocapture readonly %buffer1, i32* nocapture readonly %buffer2) {
; CHECK-LABEL: memcmp2:
; CHECK: # BB#0:
; CHECK-NEXT: lhbrx 3, 0, 3
; CHECK-NEXT: lhbrx 4, 0, 4
[CGP] use subtract or subtract-of-cmps for result of memcmp expansion As noted in the code comment, transforming this in the other direction might require a separate transform here in CGP given the block-at-a-time DAG constraint. Besides that theoretical motivation, there are 2 practical motivations for the subtract-of-cmps form: 1. The codegen for both x86 and PPC is better for this IR (though PPC could be better still). There is discussion about canonicalizing IR to the select form ( http://lists.llvm.org/pipermail/llvm-dev/2017-July/114885.html ), so we probably need to add DAG transforms for those patterns anyway, but this improves the memcmp output without waiting for that step. 2. If we allow vector-sized chunks for the load and compare, x86 is better prepared to convert that to optimal code when using subtract-of-cmps, so another prerequisite patch is avoided if we choose to enable that. Differential Revision: https://reviews.llvm.org/D34904 llvm-svn: 309597
2017-08-01 02:08:24 +08:00
; CHECK-NEXT: subf 3, 4, 3
; CHECK-NEXT: extsw 3, 3
[PowerPC] auto-generate check lines; NFC The existing check lines were more flexible, but these are small enough tests that there shouldn't be much question about register allocation. I've been hand-modifying this file as I change the CGP memcmp expansion, but that's more error-prone and time-consuming than just running the update script. llvm-svn: 306861
2017-07-01 03:20:54 +08:00
; CHECK-NEXT: blr
%t0 = bitcast i32* %buffer1 to i8*
%t1 = bitcast i32* %buffer2 to i8*
%call = tail call signext i32 @memcmp(i8* %t0, i8* %t1, i64 2)
[PPC] Inline expansion of memcmp This patch does an inline expansion of memcmp. It changes the memcmp library call into an inline expansion when the size is known at compile time and is under a target specified threshold. This expansion is implemented in CodeGenPrepare and expands into straight line code. The target specifies a maximum load size and the expansion works by using this size to load the two sources, compare, and exit early if a difference is found. It also has a special case when the memcmp result is used in a compare to zero equality. Differential Revision: https://reviews.llvm.org/D28637 llvm-svn: 304313
2017-06-01 01:12:38 +08:00
ret i32 %call
}
[PowerPC] auto-generate check lines; NFC The existing check lines were more flexible, but these are small enough tests that there shouldn't be much question about register allocation. I've been hand-modifying this file as I change the CGP memcmp expansion, but that's more error-prone and time-consuming than just running the update script. llvm-svn: 306861
2017-07-01 03:20:54 +08:00
define signext i32 @memcmp1(i32* nocapture readonly %buffer1, i32* nocapture readonly %buffer2) {
; CHECK-LABEL: memcmp1:
; CHECK: # BB#0:
; CHECK-NEXT: lbz 3, 0(3)
; CHECK-NEXT: lbz 4, 0(4)
[CGP] use subtract or subtract-of-cmps for result of memcmp expansion As noted in the code comment, transforming this in the other direction might require a separate transform here in CGP given the block-at-a-time DAG constraint. Besides that theoretical motivation, there are 2 practical motivations for the subtract-of-cmps form: 1. The codegen for both x86 and PPC is better for this IR (though PPC could be better still). There is discussion about canonicalizing IR to the select form ( http://lists.llvm.org/pipermail/llvm-dev/2017-July/114885.html ), so we probably need to add DAG transforms for those patterns anyway, but this improves the memcmp output without waiting for that step. 2. If we allow vector-sized chunks for the load and compare, x86 is better prepared to convert that to optimal code when using subtract-of-cmps, so another prerequisite patch is avoided if we choose to enable that. Differential Revision: https://reviews.llvm.org/D34904 llvm-svn: 309597
2017-08-01 02:08:24 +08:00
; CHECK-NEXT: subf 3, 4, 3
; CHECK-NEXT: extsw 3, 3
[PowerPC] auto-generate check lines; NFC The existing check lines were more flexible, but these are small enough tests that there shouldn't be much question about register allocation. I've been hand-modifying this file as I change the CGP memcmp expansion, but that's more error-prone and time-consuming than just running the update script. llvm-svn: 306861
2017-07-01 03:20:54 +08:00
; CHECK-NEXT: blr
%t0 = bitcast i32* %buffer1 to i8*
%t1 = bitcast i32* %buffer2 to i8*
%call = tail call signext i32 @memcmp(i8* %t0, i8* %t1, i64 1) #2
[PPC] Inline expansion of memcmp This patch does an inline expansion of memcmp. It changes the memcmp library call into an inline expansion when the size is known at compile time and is under a target specified threshold. This expansion is implemented in CodeGenPrepare and expands into straight line code. The target specifies a maximum load size and the expansion works by using this size to load the two sources, compare, and exit early if a difference is found. It also has a special case when the memcmp result is used in a compare to zero equality. Differential Revision: https://reviews.llvm.org/D28637 llvm-svn: 304313
2017-06-01 01:12:38 +08:00
ret i32 %call
}
[PowerPC] auto-generate check lines; NFC The existing check lines were more flexible, but these are small enough tests that there shouldn't be much question about register allocation. I've been hand-modifying this file as I change the CGP memcmp expansion, but that's more error-prone and time-consuming than just running the update script. llvm-svn: 306861
2017-07-01 03:20:54 +08:00
declare signext i32 @memcmp(i8*, i8*, i64)