On 02/16/2017 12:08 PM, Stephen Canon wrote:>> On Feb 16, 2017, at 9:12 AM, Bagel <bagel99 at gmail.com >> <mailto:bagel99 at gmail.com>> wrote: >> >> I figured that the optimization of this would bedifficult (else it would >> have already been done :-)) > > Don’t make this assumption. There’s lots of opportunities for optimization > scattered around. Some of them are left because they’re genuinely difficult, > but most either simply haven’t been noticed by anyone, or are known but simply > haven’t been done because no one has pushed for them (I’m fairly sure that this > particular optimization falls into that category—folks have known the codegen > wasn't great since these intrinsics were added, but no one has really > complained about it, so people have worked on higher-impact stuff).But I am still curious as to whether the optimization is architecture independent or must be done again for each backend? bagel
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. On Fri, Feb 17, 2017 at 8:52 PM, Bagel via llvm-dev <llvm-dev at lists.llvm.org> wrote:> On 02/16/2017 12:08 PM, Stephen Canon wrote: > >> On Feb 16, 2017, at 9:12 AM, Bagel <bagel99 at gmail.com > >> <mailto:bagel99 at gmail.com>> wrote: > >> > >> I figured that the optimization of this would bedifficult (else it would > >> have already been done :-)) > > > > Don’t make this assumption. There’s lots of opportunities for > optimization > > scattered around. Some of them are left because they’re genuinely > difficult, > > but most either simply haven’t been noticed by anyone, or are known but > simply > > haven’t been done because no one has pushed for them (I’m fairly sure > that this > > particular optimization falls into that category—folks have known the > codegen > > wasn't great since these intrinsics were added, but no one has really > > complained about it, so people have worked on higher-impact stuff). > > But I am still curious as to whether the optimization is architecture > independent or must be done again for each backend? > > bagel > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170222/c37d7548/attachment.html>
> On Feb 21, 2017, at 9:54 PM, Nemanja Ivanovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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.But what is the use case? What IR pattern it would replace? — Mehdi> > On Fri, Feb 17, 2017 at 8:52 PM, Bagel via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > On 02/16/2017 12:08 PM, Stephen Canon wrote: > >> On Feb 16, 2017, at 9:12 AM, Bagel <bagel99 at gmail.com <mailto:bagel99 at gmail.com> > >> <mailto:bagel99 at gmail.com <mailto:bagel99 at gmail.com>>> wrote: > >> > >> I figured that the optimization of this would bedifficult (else it would > >> have already been done :-)) > > > > Don’t make this assumption. There’s lots of opportunities for optimization > > scattered around. Some of them are left because they’re genuinely difficult, > > but most either simply haven’t been noticed by anyone, or are known but simply > > haven’t been done because no one has pushed for them (I’m fairly sure that this > > particular optimization falls into that category—folks have known the codegen > > wasn't great since these intrinsics were added, but no one has really > > complained about it, so people have worked on higher-impact stuff). > > But I am still curious as to whether the optimization is architecture > independent or must be done again for each backend? > > bagel > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170306/d0934382/attachment.html>