<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi James,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I would find it easier to review this if the patches were in phabricator. Can you upload them to phabricator?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Kristof<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> llvm-commits-bounces@cs.uiuc.edu [mailto:llvm-commits-bounces@cs.uiuc.edu] <b>On Behalf Of </b>James Molloy<br><b>Sent:</b> 09 February 2015 16:28<br><b>To:</b> Hal Finkel; Geoff Berry<br><b>Cc:</b> LLVM Commits<br><b>Subject:</b> Re: RFC: Tweak heuristics in SimplifyCFG<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Hi Hal,<br><br>Please find attached two patches implementing what we discussed last week. The code changes are trivial, there is some slight churn in the tests which I have attempted to justify.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Cheers,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>James<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Sat Feb 07 2015 at 10:07:56 AM James Molloy <<a href="mailto:james@jamesmolloy.co.uk">james@jamesmolloy.co.uk</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal>Hi Geoff,<br><br>The inverse transform is done in CodeGenPrepare, see TargetLoweringInfo::isPredictableSelectExpensive()<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Cheers,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>James<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Fri Feb 06 2015 at 10:44:04 PM Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:<o:p></o:p></p><p class=MsoNormal>----- 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.edu</a><br>> [mailto:<a href="mailto:llvm-commits-bounces@cs.uiuc.edu" target="_blank">llvm-commits-bounces@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/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)*(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>> > _______________________________________________<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/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<o:p></o:p></p></div></div></div></div></div></body></html>