<div dir="ltr"><div>If the transform is a performance optimization despite potentially increasing the number of instructions, that should go in the backend. Most likely that will be in DAGCombiner or a target-specific lowering file.</div><div><br></div><div>But as noted in the later reply, if this question is really about a reciprocal special-case, that becomes an extension of what we already have in instcombine. <br></div><div><br></div><div>To be clear - we're talking about FP math, and all of these transforms require some form of fast-math-flags to be valid (no matter where they are implemented).<br></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 5, 2020 at 11:11 PM raghesh <<a href="mailto:raghesh.a@gmail.com">raghesh.a@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks <span id="gmail-m_-5743496464832430974:1r7.1">Sanjay</span> for your comments.<div><br></div><div>So, if we want to add a transformation avoiding the one-use check, which one is the ideal pass? Shall we do it in -aggressive-<span id="gmail-m_-5743496464832430974:1r7.2">instcombine</span>? I came to know that if the pattern search complexity is O(n) [1] we should go for aggressive-<span id="gmail-m_-5743496464832430974:1r7.3">instcombine</span>. If it is O(1) we must do that in -<span id="gmail-m_-5743496464832430974:1r7.4">instcombine</span>. However, in my case, the complexity is still O(1) and want to avoid the one-use check.</div><div><br></div><div>[1] n is the number of instructions in the function.</div><div><br></div><div>Regards,<br clear="all"><div><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>------------------------------</div><div><span id="gmail-m_-5743496464832430974:1r7.5">Raghesh</span> <span id="gmail-m_-5743496464832430974:1r7.6">Aloor</span></div><div><span id="gmail-m_-5743496464832430974:1r7.7">AMD</span> India Pvt. Ltd.</div><div><span id="gmail-m_-5743496464832430974:1r7.8">Bengaluru</span>.</div><div>------------------------------</div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 3, 2020 at 8:02 PM Sanjay Patel <<a href="mailto:spatel@rotateright.com" target="_blank">spatel@rotateright.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>A couple more general comments:</div><div>1. There shouldn't be any correctness issues removing one-use checks (the transform should be safe independently of use-counts).</div><div>2. Ideally, you can remove a m_OneUse() from the code and run 'make check' or similar, and you will see a regression test failure because we have a 'negative' test to cover that pattern. That should make it clear that the one-use check is there intentionally and what the effect of removing it is. We've gotten better about including those kinds of regression tests over time, but I don't know what percentage of all instcombine transforms actually have that test coverage.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 30, 2019 at 7:12 PM Craig Topper via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>As a general rule, InstCombine tries not increase the total number of instructions. If X/Y has another use other than this one, then it still ends up being calculated. Without the one use check you'd trade 2 fdivs, for 1 mul (Y * Z), and 2 fdivs ((X*Y)/Z) and the original (X / Y). </div><br clear="all"><div><div dir="ltr">~Craig</div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 30, 2019 at 4:07 PM raghesh via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Dear All,<div><br></div><div>The <span id="gmail-m_-5743496464832430974gmail-m_-4425099737719817032gmail-m_-8990455333325758937gmail-m_4463031153282372788:2a4.1">InstCombine</span> pass performs the following transformation.</div><div><br></div><div>   Z / (X / Y) => (Y * Z) / X<br></div><div><br></div><div>This is performed only when operand Op1 ( (X/Y) in this case) has only one use in future. The code snippet is shown below.</div><div><br></div><div>    if (match(Op1, m_<span id="gmail-m_-5743496464832430974gmail-m_-4425099737719817032gmail-m_-8990455333325758937gmail-m_4463031153282372788:2a4.2">OneUse</span>(m_<span id="gmail-m_-5743496464832430974gmail-m_-4425099737719817032gmail-m_-8990455333325758937gmail-m_4463031153282372788:2a4.3">FDiv</span>(m_Value(X), m_Value(Y)))) &&<br>        (!<span id="gmail-m_-5743496464832430974gmail-m_-4425099737719817032gmail-m_-8990455333325758937gmail-m_4463031153282372788:2a4.4">isa</span><Constant>(Y) || !<span id="gmail-m_-5743496464832430974gmail-m_-4425099737719817032gmail-m_-8990455333325758937gmail-m_4463031153282372788:2a4.5">isa</span><Constant>(Op0))) {<br>      // Z / (X / Y) => (Y * Z) / X<br>      Value *<span id="gmail-m_-5743496464832430974gmail-m_-4425099737719817032gmail-m_-8990455333325758937gmail-m_4463031153282372788:2a4.6">YZ</span> = Builder.<span id="gmail-m_-5743496464832430974gmail-m_-4425099737719817032gmail-m_-8990455333325758937gmail-m_4463031153282372788:2a4.7">CreateFMulFMF</span>(Y, Op0, &I);<br>      return <span id="gmail-m_-5743496464832430974gmail-m_-4425099737719817032gmail-m_-8990455333325758937gmail-m_4463031153282372788:2a4.8">BinaryOperator</span>::<span id="gmail-m_-5743496464832430974gmail-m_-4425099737719817032gmail-m_-8990455333325758937gmail-m_4463031153282372788:2a4.9">CreateFDivFMF</span>(<span id="gmail-m_-5743496464832430974gmail-m_-4425099737719817032gmail-m_-8990455333325758937gmail-m_4463031153282372788:2a4.10">YZ</span>, X, &I);<br>    }</div><div><br></div><div>It would be great if someone explains if there is any issue (correctness/performance-wise) if we avoid the m_<span id="gmail-m_-5743496464832430974gmail-m_-4425099737719817032gmail-m_-8990455333325758937gmail-m_4463031153282372788:2a4.11">OueUse</span> check. What if we perform the transformation even if there are multiple uses?</div><div><br></div><div>There are similar transformations which perform the 

m_<span id="gmail-m_-5743496464832430974gmail-m_-4425099737719817032gmail-m_-8990455333325758937gmail-m_4463031153282372788:2a4.12">OueUse</span> check. We may avoid those too if there is no particular reason for the check.</div><div><br></div><div>Regards,<br><div><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>------------------------------</div><div><span id="gmail-m_-5743496464832430974gmail-m_-4425099737719817032gmail-m_-8990455333325758937gmail-m_4463031153282372788:2a4.13">Raghesh</span> <span id="gmail-m_-5743496464832430974gmail-m_-4425099737719817032gmail-m_-8990455333325758937gmail-m_4463031153282372788:2a4.14">Aloor</span></div><div><span id="gmail-m_-5743496464832430974gmail-m_-4425099737719817032gmail-m_-8990455333325758937gmail-m_4463031153282372788:2a4.15">AMD</span> India Pvt. Ltd.</div><div><span id="gmail-m_-5743496464832430974gmail-m_-4425099737719817032gmail-m_-8990455333325758937gmail-m_4463031153282372788:2a4.16">Bengaluru</span>.</div><div>------------------------------</div></div></div></div></div></div></div></div></div></div>
_______________________________________________<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="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
_______________________________________________<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="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>