<div dir="ltr"><div><div>Sorry for the delay in responding.<br></div>The use case is basically for being able to emit instructions that correspond to these nodes. For example on Power, we use these instructions that set and use the Carry bit for comparisons without using compare instructions.<br></div>One example where we would be able to make use of these would be in <a href="https://reviews.llvm.org/D28637">https://reviews.llvm.org/D28637</a>.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 7, 2017 at 7:56 AM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Feb 21, 2017, at 9:54 PM, Nemanja Ivanovic via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="m_-1365697124552070591Apple-interchange-newline"><div><div dir="ltr">I believe that providing additional intrinsics that would directly produce the ISD::ADDC/ISD::SUBC nodes would provide the additional advantage of being able to directly produce these nodes for code that doesn't have anything to do with multiprecision addition/subtraction. I am not aware of any way currently available to produce IR that will generate these nodes directly.<br></div></div></blockquote><div><br></div><div>But what is the use case? What IR pattern it would replace? </div><div><br></div><div>— </div><div>Mehdi</div><div><br></div><div><br></div><div><br></div><br><blockquote type="cite"><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 17, 2017 at 8:52 PM, Bagel via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 02/16/2017 12:08 PM, Stephen Canon wrote:<br>
>> On Feb 16, 2017, at 9:12 AM, Bagel <<a href="mailto:bagel99@gmail.com" target="_blank">bagel99@gmail.com</a><br>
</span><span>>> <mailto:<a href="mailto:bagel99@gmail.com" target="_blank">bagel99@gmail.com</a>>> wrote:<br>
>><br>
>> I figured that the optimization of this would bedifficult (else it would<br>
>> have already been done :-))<br>
><br>
> Don’t make this assumption. There’s lots of opportunities for optimization<br>
> scattered around. Some of them are left because they’re genuinely difficult,<br>
> but most either simply haven’t been noticed by anyone, or are known but simply<br>
> haven’t been done because no one has pushed for them (I’m fairly sure that this<br>
> particular optimization falls into that category—folks have known the codegen<br>
> wasn't great since these intrinsics were added, but no one has really<br>
> complained about it, so people have worked on higher-impact stuff).<br>
<br>
</span>But I am still curious as to whether the optimization is architecture<br>
independent or must be done again for each backend?<br>
<span class="m_-1365697124552070591HOEnZb"><font color="#888888"><br>
bagel<br>
</font></span><div class="m_-1365697124552070591HOEnZb"><div class="m_-1365697124552070591h5"><br>
______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>
______________________________<wbr>_________________<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/<wbr>mailman/listinfo/llvm-dev</a><br></div></blockquote></div><br></div></blockquote></div><br></div>