<div dir="ltr">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.<div><br></div><div>David</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 13, 2017 at 3:14 PM, Jun Lim <span dir="ltr"><<a href="mailto:junbuml@codeaurora.org" target="_blank">junbuml@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
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?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
-----Original Message-----<br>
From: David Li via Phabricator [mailto:<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.<wbr>org</a>]<br>
Sent: Friday, October 13, 2017 5:05 PM<br>
To: <a href="mailto:junbuml@codeaurora.org">junbuml@codeaurora.org</a>; <a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>; <a href="mailto:eraman@google.com">eraman@google.com</a>; <a href="mailto:mcrosier@codeaurora.org">mcrosier@codeaurora.org</a><br>
Cc: <a href="mailto:davidxl@google.com">davidxl@google.com</a>; <a href="mailto:aemerson@apple.com">aemerson@apple.com</a>; <a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>; <a href="mailto:kristof.beyls@arm.com">kristof.beyls@arm.com</a><br>
Subject: [PATCH] D38641: [Inline][WIP] Expose more inlining opportunities by further constraining call site arguments based on splitting an OR condition.<br>
<br>
davidxl added a comment.<br>
<br>
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.<br>
<br>
Consider this:<br>
<br>
define void @foo(i32) local_unnamed_addr #0 {<br>
<br>
  %2 = icmp eq i32 %0, 10<br>
  %3 = select i1 %2, i32 1, i32 2<br>
  tail call void @bar(i32 %3) #2<br>
  ret void<br>
<br>
}<br>
<br>
Converting Select into control flow and expose the constant propagation opportunity should be done in the same pass.<br>
<br>
Consider another example:<br>
<br>
define void @foo(i32) local_unnamed_addr #0 {<br>
<br>
  %2 = icmp eq i32 %0, 10<br>
  br i1 %2, label %3, label %4<br>
<br>
; <label>:3:                                      ; preds = %1<br>
<br>
  tail call void @bar(i32 1) #2<br>
  br label %4<br>
<br>
; <label>:4:                                      ; preds = %1, %3<br>
<br>
  %5 = phi i32 [ 1, %3 ], [ 2, %1 ]<br>
  tail call void @bar(i32 %5) #2<br>
  ret void<br>
<br>
}<br>
<br>
Hoisting 'bar' call into incoming block of the phi can also expose opportunity.<br>
<br>
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.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D38641" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D38641</a><br>
<br>
<br>
<br>
<br>
</div></div></blockquote></div><br></div>