<div class="gmail_quote">On 8 March 2012 18:49, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Author: chandlerc<br>
Date: Thu Mar  8 20:49:36 2012<br>
New Revision: 152368<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=152368&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=152368&view=rev</a><br>
Log:<br>
Undo a previous restriction on the inline cost calculation which Nick<br>
introduced. Specifically, there are cost reductions for all<br>
constant-operand icmp instructions against an alloca, regardless of<br>
whether the alloca will in fact be elligible for SROA. That means we<br>
don't want to abort the icmp reduction computation when we abort the<br>
SROA reduction computation. That in turn frees us from the need to keep<br>
a separate worklist and defer the ICmp calculations.<br>
<br>
Use this new-found freedom and some judicious function boundaries to<br>
factor the innards of computing the cost factor of any given instruction<br>
out of the loop over the instructions and into static helper functions.<br>
This greatly simplifies the code, and hopefully makes it more clear what<br>
is happening here.<br>
<br>
Reviewed by Eric Christopher. There is some concern that we'd like to<br>
ensure this doesn't get out of hand, and I plan to benchmark the effects<br>
of this change over the next few days along with some further fixes to<br>
the inline cost.<br>
</blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Modified: llvm/trunk/test/Transforms/Inline/alloca-bonus.ll<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/Inline/alloca-bonus.ll?rev=152368&r1=152367&r2=152368&view=diff" target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/Inline/alloca-bonus.ll?rev=152368&r1=152367&r2=152368&view=diff</a><br>


==============================================================================<br>
--- llvm/trunk/test/Transforms/Inline/alloca-bonus.ll (original)<br>
+++ llvm/trunk/test/Transforms/Inline/alloca-bonus.ll Thu Mar  8 20:49:36 2012<br>
@@ -81,3 +81,44 @@<br>
 bb.false:<br>
   ret void<br>
 }<br>
+<br>
+define void @outer4(i32 %A) {<br>
+; CHECK: @outer4<br>
+; CHECK-NOT: call void @inner4<br>
+  %ptr = alloca i32<br>
+  call void @inner4(i32* %ptr, i32 %A)<br>
+  ret void<br>
+}<br>
+<br>
+; %D poisons this call, scalar-repl can't handle that instruction. However, we<br>
+; still want to detect that the icmp and branch *can* be handled.<br></blockquote><div><br></div><div>Huh? There is no %D in the following function. %E?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


+define void @inner4(i32 *%ptr, i32 %A) {<br>
+  %B = getelementptr i32* %ptr, i32 %A<br>
+  %E = icmp eq i32* %ptr, null<br>
+  br i1 %E, label %bb.true, label %bb.false<br>
+bb.true:<br>
+  ; This block musn't be counted in the inline cost.<br>
+  %t1 = load i32* %ptr<br>
+  %t2 = add i32 %t1, 1<br>
+  %t3 = add i32 %t2, 1<br>
+  %t4 = add i32 %t3, 1<br>
+  %t5 = add i32 %t4, 1<br>
+  %t6 = add i32 %t5, 1<br>
+  %t7 = add i32 %t6, 1<br>
+  %t8 = add i32 %t7, 1<br>
+  %t9 = add i32 %t8, 1<br>
+  %t10 = add i32 %t9, 1<br>
+  %t11 = add i32 %t10, 1<br>
+  %t12 = add i32 %t11, 1<br>
+  %t13 = add i32 %t12, 1<br>
+  %t14 = add i32 %t13, 1<br>
+  %t15 = add i32 %t14, 1<br>
+  %t16 = add i32 %t15, 1<br>
+  %t17 = add i32 %t16, 1<br>
+  %t18 = add i32 %t17, 1<br>
+  %t19 = add i32 %t18, 1<br>
+  %t20 = add i32 %t19, 1<br>
+  ret void<br>
+bb.false:<br>
+  ret void<br>
+}<br></blockquote><div> </div></div><br>