[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]

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