<div dir="ltr"><div>I don't know anything specific about the scalar-to-vector problem that you are seeing, but you might get some ideas about how to solve it by seeing what x86 does for ops that only exist in vector form: ISD::SCALAR_TO_VECTOR and some pattern matching in tablegen?<br><br></div>Patches to get reciprocal settings out of target options and into function attributes are up for review here:<br><a href="https://reviews.llvm.org/D24816">https://reviews.llvm.org/D24816</a><br><a href="https://reviews.llvm.org/D24815">https://reviews.llvm.org/D24815</a><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 26, 2016 at 6:50 AM, Jojo Ma <span dir="ltr"><<a href="mailto:jojo.ma@linaro.org" target="_blank">jojo.ma@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi James & all,</div><div><br></div><div>I don't know if you have saw the topic disscusion about Evandro's patch on AArch64</div><div>(<a href="http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160919/391140.html" target="_blank">[llvm] r268539 - [AArch64] Use the reciprocal estimation machinery</a>).The patchset is relate </div><div>to this topic. And Actually I did a draft patch on ARM which exactly the same with this before </div><div>starting this thread. Any more discussion about this topic will help me doing things on the right way.</div><div><br></div><div>More introduce about what i was doing:</div><div>I rasied this thread because I am looking on <a href="https://llvm.org/bugs/show_bug.cgi?id=27107" target="_blank">Bug 27107</a><font size="1"><span style="color:rgb(0,0,0);background-color:rgb(208,208,208)"><font face="arial, helvetica, sans-serif">-</font></span><span style="color:rgb(0,0,0);font-family:verdana,sans-serif"> <span>LLVM misses reciprocal estimate instructions in ISel on ARMv7/8.</span></span></font></div><div>My planning about this task is :</div><div><ul><li>Emitting rsqrt[es].<br><br>Necessary preparation. I supposed we may not necessay to give a final design at this step. Just be able to emit.<br>My patch on ARM is exactly the same with Evandro's. But I was troubled with scalar-to-vector<br>when I tried to support the operation on f32 in rsqrt as my first step(rsqrt[es] of ARM is just for vector).<br><span style="font-size:13px">I would appreciate it </span>if you could help me take a look at it and show me the problems. <br><a href="https://reviews.llvm.org/D24911" target="_blank">https://reviews.llvm.org/<wbr>D24911</a><br><br>Or would it make sense if I do validating on AArch64 and porting to ARM after that?<br><br></li><li>Benchmarking on both strategies.(N-body and others)<br>Validating whether the replacing profitable or not.<br><br></li><li>Giving a final decision.<br>Hi James, Thanks again for your detailed instroduction. I think what you instroduct would be our final goal,<br>and changes based on MachineCombiner should be done for this.I have no specific progress on this yet. <br><br></li></ul></div><div>Hi Evandro,</div><div><br></div><div>I believe we will be working for the same goal, I think we could work together to make a patch that </div><div>not only won't break the LTO but also based on the context. <span>I'm a new recruit, any</span><span> comments from</span></div><div> this thread or bugzilla are welcome<span>.</span><span> </span>Thanks!</div><div><br></div><div>Best Regards,<br></div><div>Jojo</div></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 8 September 2016 at 18:59, James Molloy <span dir="ltr"><<a href="mailto:James.Molloy@arm.com" target="_blank">James.Molloy@arm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word">
Hi,
<div><br>
</div>
<div>The cost model for this transform is really difficult to get right. The latencies and throughputs for VRSQRTE/SQRT vary between microarchitectures but in general it is fair to say that;</div>
<div><br>
</div>
<div>* There are two possible fast sequences for calculating 1/sqrt(x):</div>
<div> a) (1 / x) * sqrt(x) (DIV, SQRT, MUL, where the DIV and SQRT are *independent* and can issue in parallel)</div>
<div> b) VRSQRTE + s*(VRSQRTS + MUL + MUL) where s is the number of newton-raphson steps required - 2 for 32-bit floats and 4 for doubles.</div>
<div><br>
</div>
<div>* SQRT and DIV are iterative instructions and commonly the hardware for this, because it must iterate, is not pipelined.</div>
<div> * As a consequence of this, these instructions can also commonly *exit early* if the calculation converges early.</div>
<div><br>
</div>
<div>* SQRT and DIV will almost always have a shorter latency than the equivalent VRSQRTE sequence due to the sheer number of instructions in that sequence and the early exit capability of SQRT/DIV.</div>
<div><br>
</div>
<div>So the calculation on which to choose depends on several factors:</div>
<div> 1) Is the calculation throughput or latency limited? This loop is throughput limited - the result of the sqrt is not on the cyclic critical path, so we expect to be able to vectorize it or at least look ahead and have the core execute multiple
iterations in parallel. We’d probably then want to use VRSQRTE.</div>
<div> for (int i = 0; i < n; ++i)</div>
<div> p[i] = 1.0 / q[i];</div>
<div><br>
</div>
<div> This loop is latency limited. Here, we don’t care about throughput as only one iteration can ever be executed in the core at once due to the critical path. We’d want to optimise for latency over anything else, so we’d use SQRT + DIV.</div>
<div> for (int i = 0; i < n; ++i)</div>
<div> p = 1.0 / p + q[i];</div>
<div><br>
</div>
<div> 2) Can a SQRT and DIV execute in parallel on the microarchitecture? both these instructions use similar hardware, so it’s possible that they both need the same functional unit that isn’t pipelined. If so, the sqrt() sequence’s latency gets drastically
increased and the profitability calculation changes.</div>
<div><br>
</div>
<div>The major one is latency versus throughput. This is very difficult to do at the IR level, but at the MachineInstr level we have MachineTraceMetrics which is able to analyze loops and obtain their functional unit usage (“resource height”) and critical
path length (“depth”). Using these two metrics we can determine if it’d make sense to swap the SQRT for a VRSQRTE.</div>
<div><br>
</div>
<div>So in summary it is a hard problem with a difficult cost model, that can only reasonably be done at the MachineInstr level.</div>
<div><br>
</div>
<div>Cheers,</div>
<div><br>
</div>
<div>James</div><div><div>
<div><br>
</div>
<div>
<div>
<blockquote type="cite">
<div>On 8 Sep 2016, at 10:32, Jojo Ma <<a href="mailto:jojo.ma@linaro.org" target="_blank">jojo.ma@linaro.org</a>> wrote:</div>
<br>
<div>
<div dir="ltr">
<div>Hi All,</div>
<div><br>
</div>
<div>I'm tring to use RSQRT instructions on follow case for ARM </div>
<div>(now what using is sqrt):</div>
<div>
<pre style="white-space:pre-wrap;width:50em"> 1.0 / sqrt(x)</pre>
</div>
<div>The RSQRT instructions(VRSQRTE/VRSQRTS) are vector type, </div>
<div>but above operation is scalar type. So a transformation must be </div>
<div>done(transform sqrt pattern to rsqrt).</div>
<div><br>
</div>
<div>I have completed a patch for this, but I made the transformation in the</div>
<div>backend which will leads to additional latencies.And actually it's not </div>
<div>reasonable doing transformation in backend.</div>
<div>I think it would be better done that on IR. I am a novice to llvm.I don't </div>
<div>know anything about this subject. If anyone could</div>
<div>give me some advice would be appreciated.</div>
<div><br>
</div>
<div>Thanks!</div><span class="HOEnZb"><font color="#888888">
<div><br>
</div>
-- <br>
<div>
<div dir="ltr">
<div>Best Regards,<br>
</div>
Jojo<br>
</div>
</div>
</font></span></div><span class="HOEnZb"><font color="#888888">
</font></span></div><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
</font></span></div><span class="HOEnZb"><font color="#888888">
<br>
</font></span></div></div></div><span class="HOEnZb"><font color="#888888">
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose,
or store or copy the information in any medium. Thank you.
</font></span></div><span class="HOEnZb"><font color="#888888">
</font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div>Best Regards,<br></div>Jojo<br></div></div>
</font></span></div></div>
</blockquote></div><br></div>