[PATCH] D38641: [Inline][WIP] Expose more inlining opportunities by further constraining call site arguments based on splitting an OR condition.

[Xinliang David Li via llvm-commits]

I don't think there is a  need to hook up inline cost model for this. I
consider this an pre-IPA enabler pass.   After inlining, if the mergeable
callsites remain, the later cfg simplification pass should kick in and
merge them.

David

On Fri, Oct 13, 2017 at 3:14 PM, Jun Lim <junbuml at codeaurora.org> wrote:

>
> Thanks David for the detail. I can also see many other opportunities for
> splitting/cloning call site not just for OR condition. We may be able to
> handle those step by step in a separate pass before inliner.  Don't you
> think we need to rely on the inline cost model to estimate the
> profitability before making decision for cloning a call site?
>
>
> -----Original Message-----
> From: David Li via Phabricator [mailto:reviews at reviews.llvm.org]
> Sent: Friday, October 13, 2017 5:05 PM
> To: junbuml at codeaurora.org; chandlerc at gmail.com; eraman at google.com;
> mcrosier at codeaurora.org
> Cc: davidxl at google.com; aemerson at apple.com; llvm-commits at lists.llvm.org;
> kristof.beyls at arm.com
> Subject: [PATCH] D38641: [Inline][WIP] Expose more inlining opportunities
> by further constraining call site arguments based on splitting an OR
> condition.
>
> davidxl added a comment.
>
> I see a lot of potential to make this more general. As I mentioned, this
> is similar to constant propagation based function cloning -- exposing
> specialization opportunities seems not limited to inliner though inlining
> could be the biggest customer.
>
> Consider this:
>
> define void @foo(i32) local_unnamed_addr #0 {
>
>   %2 = icmp eq i32 %0, 10
>   %3 = select i1 %2, i32 1, i32 2
>   tail call void @bar(i32 %3) #2
>   ret void
>
> }
>
> Converting Select into control flow and expose the constant propagation
> opportunity should be done in the same pass.
>
> Consider another example:
>
> define void @foo(i32) local_unnamed_addr #0 {
>
>   %2 = icmp eq i32 %0, 10
>   br i1 %2, label %3, label %4
>
> ; <label>:3:                                      ; preds = %1
>
>   tail call void @bar(i32 1) #2
>   br label %4
>
> ; <label>:4:                                      ; preds = %1, %3
>
>   %5 = phi i32 [ 1, %3 ], [ 2, %1 ]
>   tail call void @bar(i32 %5) #2
>   ret void
>
> }
>
> Hoisting 'bar' call into incoming block of the phi can also expose
> opportunity.
>
> Note that simplifyCFG pass in LLVM currently aggressively sink common code
> into the merge point -- which may lead to missing opportunities here.
> Chandler has a patch to undo that to reduce the damage done by the sinking
> but that pass is pretty late in the pipeline and won't help for
> inlining/cloning purpose.
>
>
> https://reviews.llvm.org/D38641
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20171013/541c1cae/attachment.html>