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

Jun Lim via llvm-commits llvm-commits at lists.llvm.org
Mon Oct 16 09:32:24 PDT 2017


 

> I don't think there is a  need to hook up inline cost model for this. I consider this an pre-IPA enabler pass. 

 

Do you mean that we can clone a call site whenever we detect opportunities? 

 

> After inlining, if the mergeable callsites remain, the later cfg simplification pass should kick in and merge them.

 

  If the call sites we split before inliner are not inlined, later passes may have an opportunity to merge them back. However, if we split an inlinable call site, then we might increase the code size by inlining two call sites.

 

 

 

 

From: Xinliang David Li [mailto:davidxl at google.com] 
Sent: Friday, October 13, 2017 6:18 PM
To: Jun Lim <junbuml at codeaurora.org>
Cc: reviews+D38641+public+6e61ff737b781fa2 at reviews.llvm.org; Chandler Carruth <chandlerc at gmail.com>; Easwaran Raman <eraman at google.com>; Chad Rosier <mcrosier at codeaurora.org>; aemerson at apple.com; llvm-commits <llvm-commits at lists.llvm.org>; kristof.beyls at arm.com
Subject: Re: [PATCH] D38641: [Inline][WIP] Expose more inlining opportunities by further constraining call site arguments based on splitting an OR condition.

 

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 <mailto: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 <mailto:reviews at reviews.llvm.org> ]
Sent: Friday, October 13, 2017 5:05 PM
To: junbuml at codeaurora.org <mailto:junbuml at codeaurora.org> ; chandlerc at gmail.com <mailto:chandlerc at gmail.com> ; eraman at google.com <mailto:eraman at google.com> ; mcrosier at codeaurora.org <mailto:mcrosier at codeaurora.org> 
Cc: davidxl at google.com <mailto:davidxl at google.com> ; aemerson at apple.com <mailto:aemerson at apple.com> ; llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org> ; kristof.beyls at arm.com <mailto: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/20171016/73e74c81/attachment.html>


More information about the llvm-commits mailing list