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/AArch64/machine_cse.ll

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

74 lines
2.0 KiB
LLVM
Raw Normal View History

Codegen: Tail-duplicate during placement. The tail duplication pass uses an assumed layout when making duplication decisions. This is fine, but passes up duplication opportunities that may arise when blocks are outlined. Because we want the updated CFG to affect subsequent placement decisions, this change must occur during placement. In order to achieve this goal, TailDuplicationPass is split into a utility class, TailDuplicator, and the pass itself. The pass delegates nearly everything to the TailDuplicator object, except for looping over the blocks in a function. This allows the same code to be used for tail duplication in both places. This change, in concert with outlining optional branches, allows triangle shaped code to perform much better, esepecially when the taken/untaken branches are correlated, as it creates a second spine when the tests are small enough. Issue from previous rollback fixed, and a new test was added for that case as well. Issue was worklist/scheduling/taildup issue in layout. Issue from 2nd rollback fixed, with 2 additional tests. Issue was tail merging/loop info/tail-duplication causing issue with loops that share a header block. Issue with early tail-duplication of blocks that branch to a fallthrough predecessor fixed with test case: tail-dup-branch-to-fallthrough.ll Differential revision: https://reviews.llvm.org/D18226 llvm-svn: 283934
2016-10-12 04:36:43 +08:00
; RUN: llc < %s -mtriple=aarch64-linux-gnuabi -O2 -tail-dup-placement=0 | FileCheck %s
; -tail-dup-placement causes tail duplication during layout. This breaks the
; assumptions of the test case as written (specifically, it creates an
; additional cmp instruction, creating a false positive), so we pass
; -tail-dup-placement=0 to restore the original behavior
In Machine CSE pass, the source register of a COPY machine instruction can be propagated to all its users, and this propagation could increase the probability of finding common subexpressions. If the COPY has only one user, the COPY itself can be removed. llvm-svn: 215344
2014-08-11 13:17:19 +08:00
; marked as external to prevent possible optimizations
@a = external global i32
@b = external global i32
@c = external global i32
@d = external global i32
@e = external global i32
define void @combine-sign-comparisons-by-cse(i32 *%arg) {
; CHECK: cmp
; CHECK: b.ge
; CHECK-NOT: cmp
; CHECK: b.le
entry:
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
2015-02-28 05:17:42 +08:00
%a = load i32, i32* @a, align 4
%b = load i32, i32* @b, align 4
%c = load i32, i32* @c, align 4
%d = load i32, i32* @d, align 4
%e = load i32, i32* @e, align 4
In Machine CSE pass, the source register of a COPY machine instruction can be propagated to all its users, and this propagation could increase the probability of finding common subexpressions. If the COPY has only one user, the COPY itself can be removed. llvm-svn: 215344
2014-08-11 13:17:19 +08:00
%cmp = icmp slt i32 %a, %e
br i1 %cmp, label %land.lhs.true, label %lor.lhs.false
land.lhs.true:
%cmp1 = icmp eq i32 %b, %c
br i1 %cmp1, label %return, label %if.end
lor.lhs.false:
%cmp2 = icmp sgt i32 %a, %e
br i1 %cmp2, label %land.lhs.true3, label %if.end
land.lhs.true3:
%cmp4 = icmp eq i32 %b, %d
br i1 %cmp4, label %return, label %if.end
if.end:
br label %return
return:
%retval.0 = phi i32 [ 0, %if.end ], [ 1, %land.lhs.true3 ], [ 1, %land.lhs.true ]
store i32 %a, i32 *%arg
ret void
}
[AArch64] Do 64-bit vector move of 0 and -1 by extracting from the 128-bit move Currently a vector move of 0 or -1 will use different instructions depending on the size of the vector. Using a single instruction (the 128-bit one) for both gives more opportunity for Machine CSE to eliminate instructions. Differential Revision: https://reviews.llvm.org/D53579 llvm-svn: 345270
2018-10-25 22:56:48 +08:00
define void @combine_vector_zeros(<8 x i8>* %p, <16 x i8>* %q) {
; CHECK-LABEL: combine_vector_zeros:
; CHECK: movi v[[REG:[0-9]+]].2d, #0
; CHECK-NOT: movi
; CHECK: str d[[REG]], [x0]
; CHECK: str q[[REG]], [x1]
entry:
store <8 x i8> zeroinitializer, <8 x i8>* %p
store <16 x i8> zeroinitializer, <16 x i8>* %q
ret void
}
define void @combine_vector_ones(<2 x i32>* %p, <4 x i32>* %q) {
; CHECK-LABEL: combine_vector_ones:
; CHECK: movi v[[REG:[0-9]+]].2d, #0xffffffffffffffff
; CHECK-NOT: movi
; CHECK: str d[[REG]], [x0]
; CHECK: str q[[REG]], [x1]
entry:
store <2 x i32> <i32 -1, i32 -1>, <2 x i32>* %p
store <4 x i32> <i32 -1, i32 -1, i32 -1, i32 -1>, <4 x i32>* %q
ret void
}