RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2025-01-01 08:28:19 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Removing the useless test that I added recently. It was meant as an example, but not complicated enough to merit another test.

Browse Source 
llvm-svn: 119898
This commit is contained in:
Andrew Trick 2010-11-20 07:26:51 +00:00
parent 189c10021d
commit 3166f72d7a
2 changed files with 6 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
View File

@ -76,12 +76,15 @@ LimitFPPrecision("limit-float-precision",
// load clustering may not complete in reasonable time. It is difficult to
// recognize and avoid this situation within each individual analysis, and
// future analyses are likely to have the same behavior. Limiting DAG width is
// the safe approach, and will be especially important with global DAGs. See
// 2010-11-11-ReturnBigBuffer.ll.
// the safe approach, and will be especially important with global DAGs.
//
// MaxParallelChains default is arbitrarily high to avoid affecting
// optimization, but could be lowered to improve compile time. Any ld-ld-st-st
// sequence over this should have been converted to llvm.memcpy by the frontend.
// sequence over this should have been converted to llvm.memcpy by the
// frontend. It easy to induce this behavior with .ll code such as:
// %buffer = alloca [4096 x i8]
// %data = load [4096 x i8]* %argPtr
// store [4096 x i8] %data, [4096 x i8]* %buffer
static cl::opt<unsigned>
MaxParallelChains("dag-chain-limit", cl::desc("Max parallel isel dag chains"),
cl::init(64), cl::Hidden);

32
test/CodeGen/Generic/2010-11-11-ReturnBigBuffer.ll
View File

@ -1,32 +0,0 @@
; RUN: llc < %s
; PR8287: SelectionDag scheduling time.
; Yes, some front end really produces this code. But that is a
; separate bug. This is more an example than a real test, because I
; don't know how give llvm-lit a timeout.
define void @foo([4096 x i8]* %arg1, [4096 x i8]* %arg2) {
%buffer = alloca [4096 x i8]
%pbuf = alloca [4096 x i8]*
store [4096 x i8]* %buffer, [4096 x i8]** %pbuf
%parg1 = alloca [4096 x i8]*
store [4096 x i8]* %arg1, [4096 x i8]** %parg1
%parg2 = alloca [4096 x i8]*
store [4096 x i8]* %arg2, [4096 x i8]** %parg2
; The original test case has intermediate blocks.
; Presumably something fills in "buffer".
%bufferCopy1 = load [4096 x i8]** %pbuf
%dataCopy1 = load [4096 x i8]* %bufferCopy1
%arg1Copy = load [4096 x i8]** %parg1
store [4096 x i8] %dataCopy1, [4096 x i8]* %arg1Copy
%bufferCopy2 = load [4096 x i8]** %pbuf
%dataCopy2 = load [4096 x i8]* %bufferCopy2
%arg2Copy = load [4096 x i8]** %parg2
store [4096 x i8] %dataCopy2, [4096 x i8]* %arg2Copy
ret void
}