<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, May 19, 2016 at 7:03 AM Demikhovsky, Elena <<a href="mailto:elena.demikhovsky@intel.com">elena.demikhovsky@intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div>
<p class="MsoNormal"><a name="m_-4446943922801636445__MailEndCompose">> One option would be to extend InductionDescriptor::isInductionPHI in the vectorizer to directly analyze the PHIs without SCEV support as Sanjoy suggested. I *think* that that could be sufficient to handle case
B.<u></u><u></u></a></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
</div></div><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I implemented this with FP SCEV and the code looks very structured, including SCEVExpander. Extending the existing structures without implementing FP SCEV will
be problematic.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">And my end goal is to handle case *<b>A</b>*.</span></p></div></div></blockquote><div>Ok, but there have been *numerous* requests for an explanation of why this is important, and that hasn't emerged yet.</div><div><br></div><div>We really need to have a clear understanding of the relative importance of solving these problems in order to understand the best approach.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">
<u></u><span style="font-family:"Calibri",sans-serif;color:#2f5496"><span>-<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span dir="LTR"></span><b><i><span style="color:#2f5496"> Elena<u></u><u></u></span></i></b></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<div style="border:none;border-right:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><a name="m_-4446943922801636445______replyseparator"></a><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"> <a href="mailto:anemet@apple.com" target="_blank">anemet@apple.com</a> [mailto:<a href="mailto:anemet@apple.com" target="_blank">anemet@apple.com</a>]
<br>
<b>Sent:</b> Thursday, May 19, 2016 07:43<br>
<b>To:</b> Sanjoy Das <<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>><br>
<b>Cc:</b> Demikhovsky, Elena <<a href="mailto:elena.demikhovsky@intel.com" target="_blank">elena.demikhovsky@intel.com</a>>; Saito, Hideki <<a href="mailto:hideki.saito@intel.com" target="_blank">hideki.saito@intel.com</a>>; llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>; Andrew Trick <<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>></span></p></div></div></div></div></div><div lang="EN-US" link="blue" vlink="purple"><div><div style="border:none;border-right:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><br>
<b>Subject:</b> Re: [llvm-dev] Working on FP SCEV Analysis<u></u><u></u></span></p></div></div></div></div></div><div lang="EN-US" link="blue" vlink="purple"><div><div style="border:none;border-right:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On May 18, 2016, at 12:17 PM, Sanjoy Das via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
</div></blockquote></div></div></div></div><div lang="EN-US" link="blue" vlink="purple"><div><div style="border:none;border-right:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><span style="font-size:7.5pt;font-family:"Helvetica",sans-serif"><br>
<br>
Demikhovsky, Elena wrote:<br style="text-align:start;word-spacing:0px">
<br>
</span><u></u><u></u></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:7.5pt;font-family:"Helvetica",sans-serif">> Even then, I'd personally want to see further evidence of why the<br>
correct solution is to model the floating point IV in SCEV rather than<br>
find a more powerful way of converting the IV to an integer that models<br>
> the non-integer values taken on by the IV. As an example, if the use<br>
case is the following code with appropriate flags to relax IEEE<br>
semantics so this looks like normal algabra etc:<br>
<br>
> for (float f = 0.01f; f < 1.0f; f += 0.01f) ç **A**<br>
<br>
...<br>
<br>
> I'd rather see us cleverly turn it into:<br>
<br>
> float f = 0.01f;<br>
<br>
> for (int i = 1; i < 100; i += 1, f += 0.01f) ç **B**<br>
<br>
I can later try to enhance IndVarSimplify::handleFloatingPointIV() in<br>
order to convert**A** to **B**.<br>
<br>
But **B** is exactly the case I’m starting from. The main IV “i” is<br>
integer. The variable “f” is also considered as IV in this loop.<br>
<br>
And this loop is not vectorized because “f” is floating point.<br>
<br>
I don’t think that the case **B** is uncommon.<u></u><u></u></span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:7.5pt;font-family:"Helvetica",sans-serif"><br>
If B is the case we actually care about, I'd say changing SCEV to work with floating points is an overkill. How would you expect an SCEVFAddExpr to help vectorize B, other than tell you what the initial value and the increment is (and these can be found with
a simple value analysis)?</span><u></u><u></u></p>
</div>
</blockquote></div></div></div></div><div lang="EN-US" link="blue" vlink="purple"><div><div style="border:none;border-right:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">One option would be to extend InductionDescriptor::isInductionPHI in the vectorizer to directly analyze the PHIs without SCEV support as Sanjoy suggested. I *think* that that could be sufficient to handle case B.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Then if we find other pressing cases to handle we can rethink the strategy.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Also the current diagnostics is pretty bad for Hideki’s testcase with TTT as float. This is what we currently report with -Rpass-analysis=loop-vectorize:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div></div><div lang="EN-US" link="blue" vlink="purple"><div><div style="border:none;border-right:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<blockquote style="margin-left:30.0pt;margin-right:0cm">
<div>
<div>
<div>
<p class="MsoNormal">/tmp/sss.c:3:6: remark: loop not vectorized: value that could not be<u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> identified as reduction is used outside the loop<u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> [-Rpass-analysis=loop-vectorize]<u></u><u></u></p>
</div>
</div>
</div>
</blockquote>
<div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I have no clue why we say that the value is used outside the loop. I think this should just say that we have a loop-variant value that we couldn’t identify either as an induction or as a reduction.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Adam<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:7.5pt;font-family:"Helvetica",sans-serif"><br>
If we're interested in handling complex variants of A directly: computing trip counts, proving away predicates etc. without translating the loops to use integer IVs (perhaps because we can't legally do so), then I can see FP-SCEV as a reasonable implementation
strategy, but it looks like the general consensus is that such cases are rare and generally not worth optimizing?<br>
<br>
-- Sanjoy<br>
<br style="text-align:start;word-spacing:0px">
<br>
</span><u></u><u></u></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:7.5pt;font-family:"Helvetica",sans-serif"><br>
-*/Elena/*<br>
<br>
---------------------------------------------------------------------<br>
Intel Israel (74) Limited<br>
<br>
This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.<u></u><u></u></span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:7.5pt;font-family:"Helvetica",sans-serif">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></span><u></u><u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div></div></div><div lang="EN-US" link="blue" vlink="purple">
<p>---------------------------------------------------------------------<br>
Intel Israel (74) Limited</p>
<p>This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.</p></div></blockquote></div></div>