[llvm-commits] [llvm] r152368 - in /llvm/trunk: lib/Analysis/InlineCost.cpp test/Transforms/Inline/alloca-bonus.ll

[Nick Lewycky]

On 8 March 2012 18:49, Chandler Carruth <chandlerc at gmail.com> wrote:

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

Modified: llvm/trunk/test/Transforms/Inline/alloca-bonus.ll
> URL:
> http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/Inline/alloca-bonus.ll?rev=152368&r1=152367&r2=152368&view=diff
>
> ==============================================================================
> --- llvm/trunk/test/Transforms/Inline/alloca-bonus.ll (original)
> +++ llvm/trunk/test/Transforms/Inline/alloca-bonus.ll Thu Mar  8 20:49:36
> 2012
> @@ -81,3 +81,44 @@
>  bb.false:
>   ret void
>  }
> +
> +define void @outer4(i32 %A) {
> +; CHECK: @outer4
> +; CHECK-NOT: call void @inner4
> +  %ptr = alloca i32
> +  call void @inner4(i32* %ptr, i32 %A)
> +  ret void
> +}
> +
> +; %D poisons this call, scalar-repl can't handle that instruction.
> However, we
> +; still want to detect that the icmp and branch *can* be handled.
>

Huh? There is no %D in the following function. %E?


> +define void @inner4(i32 *%ptr, i32 %A) {
> +  %B = getelementptr i32* %ptr, i32 %A
> +  %E = icmp eq i32* %ptr, null
> +  br i1 %E, label %bb.true, label %bb.false
> +bb.true:
> +  ; This block musn't be counted in the inline cost.
> +  %t1 = load i32* %ptr
> +  %t2 = add i32 %t1, 1
> +  %t3 = add i32 %t2, 1
> +  %t4 = add i32 %t3, 1
> +  %t5 = add i32 %t4, 1
> +  %t6 = add i32 %t5, 1
> +  %t7 = add i32 %t6, 1
> +  %t8 = add i32 %t7, 1
> +  %t9 = add i32 %t8, 1
> +  %t10 = add i32 %t9, 1
> +  %t11 = add i32 %t10, 1
> +  %t12 = add i32 %t11, 1
> +  %t13 = add i32 %t12, 1
> +  %t14 = add i32 %t13, 1
> +  %t15 = add i32 %t14, 1
> +  %t16 = add i32 %t15, 1
> +  %t17 = add i32 %t16, 1
> +  %t18 = add i32 %t17, 1
> +  %t19 = add i32 %t18, 1
> +  %t20 = add i32 %t19, 1
> +  ret void
> +bb.false:
> +  ret void
> +}
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120308/9d9069bf/attachment.html>