[llvm-commits] [llvm] r119898 - in /llvm/trunk: lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp test/CodeGen/Generic/2010-11-11-ReturnBigBuffer.ll

[Andrew Trick]

Author: atrick
Date: Sat Nov 20 01:26:51 2010
New Revision: 119898

URL: http://llvm.org/viewvc/llvm-project?rev=119898&view=rev
Log:
Removing the useless test that I added recently. It was meant as an example, but not complicated enough to merit another test.

Removed:
    llvm/trunk/test/CodeGen/Generic/2010-11-11-ReturnBigBuffer.ll
Modified:
    llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp

Modified: llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp?rev=119898&r1=119897&r2=119898&view=diff
==============================================================================
--- llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp (original)
+++ llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp Sat Nov 20 01:26:51 2010
@@ -76,12 +76,15 @@
 // 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);

Removed: llvm/trunk/test/CodeGen/Generic/2010-11-11-ReturnBigBuffer.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/Generic/2010-11-11-ReturnBigBuffer.ll?rev=119897&view=auto
==============================================================================
--- llvm/trunk/test/CodeGen/Generic/2010-11-11-ReturnBigBuffer.ll (original)
+++ llvm/trunk/test/CodeGen/Generic/2010-11-11-ReturnBigBuffer.ll (removed)
@@ -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
-}