RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-22 18:54:02 +01:00
Code Issues Projects Releases Wiki Activity
28d769100d
llvm-mirror/test/Transforms/LoopUnroll/unroll-header-exiting-with-phis.ll

99 lines
4.0 KiB
LLVM
Raw Normal View History

[LoopUnroll] Handle certain PHIs in full unrolling properly Summary: When reconstructing the CFG of the loop after unrolling, LoopUnroll could in some cases remove the phi operands of loop-carried values instead of preserving them, resulting in undef phi values after loop unrolling. When doing this reconstruction, avoid removing incoming phi values for phis in the successor blocks if the successor is the block we are jumping to anyway. Patch-by: ebevhan Reviewers: fhahn, efriedma Reviewed By: fhahn Subscribers: bjope, lebedev.ri, zzheng, dmgreen, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66334 llvm-svn: 369886
2019-08-26 11:29:53 +02:00
; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
; RUN: opt < %s -S -loop-unroll -unroll-allow-partial | FileCheck %s
; The phi which acts as input to func should not be undef. It should
; have its loop-carried value (the load in for.cond) replaced accordingly
; after unrolling the loop.
define i16 @full_unroll(i16* %A) {
; CHECK-LABEL: @full_unroll(
; CHECK-NEXT: entry:
; CHECK-NEXT: br label [[FOR_COND:%.*]]
; CHECK: for.cond:
; CHECK-NEXT: br label [[FOR_COND_CLEANUP3:%.*]]
; CHECK: for.cond.cleanup:
; CHECK-NEXT: [[DOTLCSSA10_LCSSA:%.*]] = phi i16 [ [[TMP2_2:%.*]], [[FOR_COND_CLEANUP3_2:%.*]] ]
; CHECK-NEXT: [[TMP3:%.*]] = call i16 @func(i16 [[DOTLCSSA10_LCSSA]])
; CHECK-NEXT: ret i16 0
; CHECK: for.cond.cleanup3:
; CHECK-NEXT: br label [[FOR_COND_CLEANUP3_1:%.*]]
; CHECK: for.cond.cleanup3.1:
Do actual DCE in LoopUnroll (try 4) Turns out simplifyLoopIVs sometimes returns a non-dead instruction in it's DeadInsts out param. I had done a bit of NFC cleanup which was only NFC if simplifyLoopIVs obeyed it's documentation. I'm simplfy dropping that part of the change. Commit message from try 3: Recommitting after fixing a bug found post commit. Amusingly, try 1 had been correct, and by reverting to incorporate last minute review feedback, I introduce the bug. Oops. :) Original commit message: The problem was that recursively deleting an instruction can delete instructions beyond the current iterator (via a dead phi), thus invalidating iteration. Test case added in LoopUnroll/dce.ll to cover this case. LoopUnroll does a limited DCE pass after unrolling, but if you have a chain of dead instructions, it only deletes the last one. Improve the code to recursively delete all trivially dead instructions. Differential Revision: https://reviews.llvm.org/D102511
2021-05-19 18:50:21 +02:00
; CHECK-NEXT: [[PTR_2:%.*]] = getelementptr inbounds i16, i16* [[A:%.*]], i64 2
Infer alignment of unmarked loads in IR/bitcode parsing. For IR generated by a compiler, this is really simple: you just take the datalayout from the beginning of the file, and apply it to all the IR later in the file. For optimization testcases that don't care about the datalayout, this is also really simple: we just use the default datalayout. The complexity here comes from the fact that some LLVM tools allow overriding the datalayout: some tools have an explicit flag for this, some tools will infer a datalayout based on the code generation target. Supporting this properly required plumbing through a bunch of new machinery: we want to allow overriding the datalayout after the datalayout is parsed from the file, but before we use any information from it. Therefore, IR/bitcode parsing now has a callback to allow tools to compute the datalayout at the appropriate time. Not sure if I covered all the LLVM tools that want to use the callback. (clang? lli? Misc IR manipulation tools like llvm-link?). But this is at least enough for all the LLVM regression tests, and IR without a datalayout is not something frontends should generate. This change had some sort of weird effects for certain CodeGen regression tests: if the datalayout is overridden with a datalayout with a different program or stack address space, we now parse IR based on the overridden datalayout, instead of the one written in the file (or the default one, if none is specified). This broke a few AVR tests, and one AMDGPU test. Outside the CodeGen tests I mentioned, the test changes are all just fixing CHECK lines and moving around datalayout lines in weird places. Differential Revision: https://reviews.llvm.org/D78403
2020-05-14 21:59:45 +02:00
; CHECK-NEXT: [[TMP2_2]] = load i16, i16* [[PTR_2]], align 2
[LoopUnroll] Handle certain PHIs in full unrolling properly Summary: When reconstructing the CFG of the loop after unrolling, LoopUnroll could in some cases remove the phi operands of loop-carried values instead of preserving them, resulting in undef phi values after loop unrolling. When doing this reconstruction, avoid removing incoming phi values for phis in the successor blocks if the successor is the block we are jumping to anyway. Patch-by: ebevhan Reviewers: fhahn, efriedma Reviewed By: fhahn Subscribers: bjope, lebedev.ri, zzheng, dmgreen, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66334 llvm-svn: 369886
2019-08-26 11:29:53 +02:00
; CHECK-NEXT: br label [[FOR_COND_CLEANUP3_2]]
; CHECK: for.cond.cleanup3.2:
; CHECK-NEXT: br i1 false, label [[FOR_COND_CLEANUP3_3:%.*]], label [[FOR_COND_CLEANUP:%.*]]
; CHECK: for.cond.cleanup3.3:
; CHECK-NEXT: unreachable
;
entry:
br label %for.cond
for.cond: ; preds = %for.cond.cleanup3, %entry
%.lcssa10 = phi i16 [ 123, %entry ], [ %.lcssa, %for.cond.cleanup3 ]
%i.0 = phi i64 [ 0, %entry ], [ %inc9, %for.cond.cleanup3 ]
%ptr = getelementptr inbounds i16, i16* %A, i64 %i.0
%tmp2 = load i16, i16* %ptr
%cmp = icmp ult i64 %i.0, 3
br i1 %cmp, label %for.cond.cleanup3, label %for.cond.cleanup
for.cond.cleanup: ; preds = %for.cond
%.lcssa10.lcssa = phi i16 [ %.lcssa10, %for.cond ]
%tmp3 = call i16 (i16) @func(i16 %.lcssa10.lcssa)
ret i16 0
for.cond.cleanup3: ; preds = %for.cond
%.lcssa = phi i16 [ %tmp2, %for.cond ]
%inc9 = add i64 %i.0, 1
br label %for.cond
}
define i16 @partial_unroll(i16* %A) {
; CHECK-LABEL: @partial_unroll(
; CHECK-NEXT: entry:
; CHECK-NEXT: br label [[FOR_COND:%.*]]
; CHECK: for.cond:
; CHECK-NEXT: [[I_0:%.*]] = phi i64 [ 0, [[ENTRY:%.*]] ], [ [[INC9_2:%.*]], [[FOR_COND_CLEANUP3_2:%.*]] ]
; CHECK-NEXT: br label [[FOR_COND_CLEANUP3:%.*]]
; CHECK: for.cond.cleanup:
; CHECK-NEXT: [[DOTLCSSA10_LCSSA:%.*]] = phi i16 [ [[TMP2_1:%.*]], [[FOR_COND_CLEANUP3_1:%.*]] ]
; CHECK-NEXT: [[TMP3:%.*]] = call i16 @func(i16 [[DOTLCSSA10_LCSSA]])
; CHECK-NEXT: ret i16 0
; CHECK: for.cond.cleanup3:
; CHECK-NEXT: [[INC9:%.*]] = add nuw nsw i64 [[I_0]], 1
Do actual DCE in LoopUnroll (try 4) Turns out simplifyLoopIVs sometimes returns a non-dead instruction in it's DeadInsts out param. I had done a bit of NFC cleanup which was only NFC if simplifyLoopIVs obeyed it's documentation. I'm simplfy dropping that part of the change. Commit message from try 3: Recommitting after fixing a bug found post commit. Amusingly, try 1 had been correct, and by reverting to incorporate last minute review feedback, I introduce the bug. Oops. :) Original commit message: The problem was that recursively deleting an instruction can delete instructions beyond the current iterator (via a dead phi), thus invalidating iteration. Test case added in LoopUnroll/dce.ll to cover this case. LoopUnroll does a limited DCE pass after unrolling, but if you have a chain of dead instructions, it only deletes the last one. Improve the code to recursively delete all trivially dead instructions. Differential Revision: https://reviews.llvm.org/D102511
2021-05-19 18:50:21 +02:00
; CHECK-NEXT: [[PTR_1:%.*]] = getelementptr inbounds i16, i16* [[A:%.*]], i64 [[INC9]]
Infer alignment of unmarked loads in IR/bitcode parsing. For IR generated by a compiler, this is really simple: you just take the datalayout from the beginning of the file, and apply it to all the IR later in the file. For optimization testcases that don't care about the datalayout, this is also really simple: we just use the default datalayout. The complexity here comes from the fact that some LLVM tools allow overriding the datalayout: some tools have an explicit flag for this, some tools will infer a datalayout based on the code generation target. Supporting this properly required plumbing through a bunch of new machinery: we want to allow overriding the datalayout after the datalayout is parsed from the file, but before we use any information from it. Therefore, IR/bitcode parsing now has a callback to allow tools to compute the datalayout at the appropriate time. Not sure if I covered all the LLVM tools that want to use the callback. (clang? lli? Misc IR manipulation tools like llvm-link?). But this is at least enough for all the LLVM regression tests, and IR without a datalayout is not something frontends should generate. This change had some sort of weird effects for certain CodeGen regression tests: if the datalayout is overridden with a datalayout with a different program or stack address space, we now parse IR based on the overridden datalayout, instead of the one written in the file (or the default one, if none is specified). This broke a few AVR tests, and one AMDGPU test. Outside the CodeGen tests I mentioned, the test changes are all just fixing CHECK lines and moving around datalayout lines in weird places. Differential Revision: https://reviews.llvm.org/D78403
2020-05-14 21:59:45 +02:00
; CHECK-NEXT: [[TMP2_1]] = load i16, i16* [[PTR_1]], align 2
[LoopUnroll] Handle certain PHIs in full unrolling properly Summary: When reconstructing the CFG of the loop after unrolling, LoopUnroll could in some cases remove the phi operands of loop-carried values instead of preserving them, resulting in undef phi values after loop unrolling. When doing this reconstruction, avoid removing incoming phi values for phis in the successor blocks if the successor is the block we are jumping to anyway. Patch-by: ebevhan Reviewers: fhahn, efriedma Reviewed By: fhahn Subscribers: bjope, lebedev.ri, zzheng, dmgreen, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66334 llvm-svn: 369886
2019-08-26 11:29:53 +02:00
; CHECK-NEXT: br label [[FOR_COND_CLEANUP3_1]]
; CHECK: for.cond.cleanup3.1:
; CHECK-NEXT: [[INC9_1:%.*]] = add nuw nsw i64 [[INC9]], 1
; CHECK-NEXT: [[CMP_2:%.*]] = icmp ult i64 [[INC9_1]], 200
; CHECK-NEXT: br i1 [[CMP_2]], label [[FOR_COND_CLEANUP3_2]], label [[FOR_COND_CLEANUP:%.*]]
; CHECK: for.cond.cleanup3.2:
; CHECK-NEXT: [[INC9_2]] = add nuw nsw i64 [[INC9_1]], 1
; CHECK-NEXT: br label [[FOR_COND]]
;
entry:
br label %for.cond
for.cond: ; preds = %for.cond.cleanup3, %entry
%.lcssa10 = phi i16 [ 123, %entry ], [ %.lcssa, %for.cond.cleanup3 ]
%i.0 = phi i64 [ 0, %entry ], [ %inc9, %for.cond.cleanup3 ]
%ptr = getelementptr inbounds i16, i16* %A, i64 %i.0
%tmp2 = load i16, i16* %ptr
%cmp = icmp ult i64 %i.0, 200
br i1 %cmp, label %for.cond.cleanup3, label %for.cond.cleanup
for.cond.cleanup: ; preds = %for.cond
%.lcssa10.lcssa = phi i16 [ %.lcssa10, %for.cond ]
%tmp3 = call i16 (i16) @func(i16 %.lcssa10.lcssa)
ret i16 0
for.cond.cleanup3: ; preds = %for.cond
%.lcssa = phi i16 [ %tmp2, %for.cond ]
%inc9 = add i64 %i.0, 1
br label %for.cond
}
declare i16 @func(i16)
Reference in New Issue Copy Permalink