<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 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
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;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
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-US 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, Hal,<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’ve been looking into a related issue, and would appreciate your input on it. We currently convert branches to selects in SimplifyCFG, but we don’t do the opposite anywhere at the IR level from what I can tell. It seems like it might be beneficial to do this conversion in cases where the un-if converted code would be rejected by the cost heuristic that was being discussed below. Code sinking also comes into play, since ideally we would consider the branching case cost with code sunk into the then/else blocks where possible/profitable. Come to think of it, it seems like we would want to do some sinking before the SimplifyCFG case as well to make a better decision.<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'>Any thoughts on this?<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><div style='mso-element:para-border-div;border:dashed #2F6FAB 1.0pt;padding:12.0pt 12.0pt 12.0pt 12.0pt;background:#F9F9F9'><p class=MsoNormal style='line-height:15.6pt;background:#F9F9F9;border:none;padding:0in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>--<o:p></o:p></span></p><p class=MsoNormal style='line-height:15.6pt;background:#F9F9F9;border:none;padding:0in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Geoff Berry<o:p></o:p></span></p><p class=MsoNormal style='line-height:15.6pt;background:#F9F9F9;border:none;padding:0in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Employee of Qualcomm Innovation Center, Inc.<o:p></o:p></span></p><p class=MsoNormal style='line-height:15.6pt;background:#F9F9F9;border:none;padding:0in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<o:p></o:p></span></p></div><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><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",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> Friday, February 06, 2015 12:01 PM<br><b>To:</b> Hal Finkel<br><b>Cc:</b> LLVM Commits<br><b>Subject:</b> Re: RFC: Tweak heuristics in SimplifyCFG<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'>Hi Hal,<o:p></o:p></p><div><p class=MsoNormal>That's a really good point, I'm on board with that. I'll cook up a patch soon and send it for review.<o:p></o:p></p></div><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 4:53:44 PM Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal>----- 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 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 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 SimplifyCFG did not have its own list of cheap instructions (I'm referring to ComputeSpeculationCost in lib/Transforms/Utils/SimplifyCFG.cpp), but rather used the existing TTI interface for this. SimplifyCFG already now uses TTI for other things, and I think this is a natural enhancement.<br><br>I think that we should call TTI.getUserCost(&I) (which is the same interface used by the inliner's cost analysis, the loop unroller, etc.), and hoist an unlimited number of instructions marked as TargetTransformInfo::TCC_Free and some limited number of instructions marked as TCC_Basic. The idea is that the total cost of the instructions should equal (phi-node-folding-threshold)*(TCC_Basic).<br><br>This also provides a natural way to turn off these optimizations for fadd, etc. on targets that don't have hardware-implemented floating 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<o:p></o:p></p></blockquote></div></div></body></html>