<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 21, 2017, at 9:54 PM, Nemanja Ivanovic via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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 class=""></div></div></blockquote><div><br class=""></div><div>But what is the use case? What IR pattern it would replace? </div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Feb 17, 2017 at 8:52 PM, Bagel via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02/16/2017 12:08 PM, Stephen Canon wrote:<br class="">
>> On Feb 16, 2017, at 9:12 AM, Bagel <<a href="mailto:bagel99@gmail.com" class="">bagel99@gmail.com</a><br class="">
</span><span class="">>> <mailto:<a href="mailto:bagel99@gmail.com" class="">bagel99@gmail.com</a>>> wrote:<br class="">
>><br class="">
>> I figured that the optimization of this would bedifficult (else it would<br class="">
>> have already been done :-))<br class="">
><br class="">
> Don’t make this assumption. There’s lots of opportunities for optimization<br class="">
> scattered around. Some of them are left because they’re genuinely difficult,<br class="">
> but most either simply haven’t been noticed by anyone, or are known but simply<br class="">
> haven’t been done because no one has pushed for them (I’m fairly sure that this<br class="">
> particular optimization falls into that category—folks have known the codegen<br class="">
> wasn't great since these intrinsics were added, but no one has really<br class="">
> complained about it, so people have worked on higher-impact stuff).<br class="">
<br class="">
</span>But I am still curious as to whether the optimization is architecture<br class="">
independent or must be done again for each backend?<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
bagel<br class="">
</font></span><div class="HOEnZb"><div class="h5"><br class="">
______________________________<wbr class="">_________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
</div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>