<div dir="ltr">Hi Geoff,<br><br>The inverse transform is done in CodeGenPrepare, see TargetLoweringInfo::isPredictableSelectExpensive()<div><br></div><div>Cheers,</div><div><br></div><div>James</div></div><br><div class="gmail_quote">On Fri Feb 06 2015 at 10:44:04 PM Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">----- Original Message -----<br>
> From: "Geoff Berry" <<a href="mailto:gberry@codeaurora.org" target="_blank">gberry@codeaurora.org</a>><br>
> To: "James Molloy" <<a href="mailto:james@jamesmolloy.co.uk" target="_blank">james@jamesmolloy.co.uk</a>>, "Hal Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>><br>
> Cc: "LLVM Commits" <<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a>><br>
> Sent: Friday, February 6, 2015 4:38:27 PM<br>
> Subject: RE: RFC: Tweak heuristics in SimplifyCFG<br>
><br>
><br>
><br>
><br>
> Hi James, Hal,<br>
><br>
><br>
><br>
> I’ve been looking into a related issue, and would appreciate your<br>
> input on it. We currently convert branches to selects in<br>
> SimplifyCFG, but we don’t do the opposite anywhere at the IR level<br>
> from what I can tell.<br>
> It seems like it might be beneficial to do<br>
> this conversion in cases where the un-if converted code would be<br>
> rejected by the cost heuristic that was being discussed below. Code<br>
> sinking also comes into play, since ideally we would consider the<br>
> branching case cost with code sunk into the then/else blocks where<br>
> possible/profitable. Come to think of it, it seems like we would<br>
> want to do some sinking before the SimplifyCFG case as well to make<br>
> a better decision.<br>
><br>
><br>
><br>
> Any thoughts on this?<br>
><br>
<br>
I think that I understand what you're saying, but could you provide a couple quick examples? I'm somewhat skeptical because creating branches from selects generically makes optimization and analysis harder. As a result, we generally delay this until CodeGen when our modeling is more precise.<br>
<br>
 -Hal<br>
<br>
><br>
><br>
> Thanks,<br>
><br>
><br>
><br>
><br>
> --<br>
><br>
> Geoff Berry<br>
><br>
> Employee of Qualcomm Innovation Center, Inc.<br>
><br>
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a<br>
> Linux Foundation Collaborative Project<br>
><br>
><br>
><br>
> From: <a href="mailto:llvm-commits-bounces@cs.uiuc.edu" target="_blank">llvm-commits-bounces@cs.uiuc.<u></u>edu</a><br>
> [mailto:<a href="mailto:llvm-commits-bounces@cs.uiuc.edu" target="_blank">llvm-commits-bounces@<u></u>cs.uiuc.edu</a>] On Behalf Of James Molloy<br>
> Sent: Friday, February 06, 2015 12:01 PM<br>
> To: Hal Finkel<br>
> Cc: LLVM Commits<br>
> Subject: Re: RFC: Tweak heuristics in SimplifyCFG<br>
><br>
><br>
><br>
><br>
> Hi Hal,<br>
><br>
><br>
> That's a really good point, I'm on board with that. I'll cook up a<br>
> patch soon and send it for review.<br>
><br>
><br>
><br>
><br>
><br>
> Cheers,<br>
><br>
><br>
><br>
><br>
><br>
> James<br>
><br>
><br>
><br>
><br>
> On Fri Feb 06 2015 at 4:53:44 PM Hal Finkel < <a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a> ><br>
> wrote:<br>
><br>
><br>
><br>
> ----- Original Message -----<br>
> > From: "James Molloy" < <a href="mailto:james@jamesmolloy.co.uk" target="_blank">james@jamesmolloy.co.uk</a> ><br>
> > To: "LLVM Commits" < <a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a> ><br>
> > Sent: Friday, February 6, 2015 9:00:33 AM<br>
> > Subject: RFC: Tweak heuristics in SimplifyCFG<br>
> ><br>
> > Hi all,<br>
> ><br>
> ><br>
> > I've been looking at why we generate poor code for idiomatic stuff<br>
> > like clamp() and abs().<br>
> ><br>
> ><br>
> > Clamp normally looks like this:<br>
> ><br>
> ><br>
> > T clamp(T a, T b, T c) { return (a < b) ? b : ((a > c) ? c : a); }<br>
> ><br>
> ><br>
> > We currently produce the following IR for this:<br>
> ><br>
> ><br>
> > define i32 @clamp2(i32 %a, i32 %b, i32 %c) #0 {<br>
> > entry:<br>
> > %cmp = icmp sgt i32 %a, %c<br>
> > br i1 %cmp, label %cond.end4, label %cond.false<br>
> ><br>
> ><br>
> > cond.false:<br>
> > %cmp1 = icmp slt i32 %a, %b<br>
> > %cond = select i1 %cmp1, i32 %b, i32 %a<br>
> > br label %cond.end4<br>
> ><br>
> ><br>
> > cond.end4:<br>
> > %cond5 = phi i32 [ %cond, %cond.false ], [ %c, %entry ]<br>
> > ret i32 %cond5<br>
> > }<br>
> ><br>
> ><br>
> > This is multi-block so makes later optimizations more awkward, such<br>
> > as loop vectorization and loop rerolling. SimplifyCFG can convert<br>
> > this into "icmp; select; icmp; select", but doesn't because it has<br>
> > quite a conservative heuristic - it'll only ever hoist one (cheap)<br>
> > instruction into the dominating block.<br>
> ><br>
> ><br>
> > I think this is too conservative - given the potential gains later<br>
> > on<br>
> > in the optimizer from flattening basic blocks (and that<br>
> > CodegenPrepare can remove selects again!) - we should be more<br>
> > aggressive here.<br>
> ><br>
> ><br>
> > My suggestions are:<br>
> > - Up -phi-node-folding-threshold from 1 to 3.<br>
> > - Add "fcmp", "fadd" and "fsub" to the list of cheap instructions<br>
> > to<br>
> > hoist. (fadd and fsub to make abs() work!)<br>
> ><br>
> > Would anyone object to this? I'll have benchmark results on AArch64<br>
> > by the end of the weekend.<br>
><br>
> This sounds good to be. Regarding the second point, I'd rather that<br>
> SimplifyCFG did not have its own list of cheap instructions (I'm<br>
> referring to ComputeSpeculationCost in<br>
> lib/Transforms/Utils/<u></u>SimplifyCFG.cpp), but rather used the existing<br>
> TTI interface for this. SimplifyCFG already now uses TTI for other<br>
> things, and I think this is a natural enhancement.<br>
><br>
> I think that we should call TTI.getUserCost(&I) (which is the same<br>
> interface used by the inliner's cost analysis, the loop unroller,<br>
> etc.), and hoist an unlimited number of instructions marked as<br>
> TargetTransformInfo::TCC_Free and some limited number of<br>
> instructions marked as TCC_Basic. The idea is that the total cost of<br>
> the instructions should equal<br>
> (phi-node-folding-threshold)*(<u></u>TCC_Basic).<br>
><br>
> This also provides a natural way to turn off these optimizations for<br>
> fadd, etc. on targets that don't have hardware-implemented floating<br>
> point.<br>
><br>
> -Hal<br>
><br>
> ><br>
> ><br>
> > Cheers,<br>
> ><br>
> ><br>
> > James<br>
> ><br>
> ><br>
> > ______________________________<u></u>_________________<br>
> > llvm-commits mailing list<br>
> > <a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><br>
> ><br>
><br>
> --<br>
> Hal Finkel<br>
> Assistant Computational Scientist<br>
> Leadership Computing Facility<br>
> Argonne National Laboratory<br>
<br>
--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</blockquote></div>