lebedev.ri added a comment. In D67661#1673993 <https://reviews.llvm.org/D67661#1673993>, @lebedev.ri wrote:
> In D67661#1673918 <https://reviews.llvm.org/D67661#1673918>, @s.egerton wrote: > > > Sorry I misread your original comment. > > > (which one?) > > > These functions exist so that we can guarantee that these particular > > instructions will be emitted; > > Sure, that makes sense. > > > the other option was LLVM IR intrinsics and Clang builtins, this was the > > other patch (https://reviews.llvm.org/D66479). > > We are planning on abandoning that patch in favour of this one after the > > discussions on the patch and the mailing list. > > I sure did comment that both of these approaches (emitting inline asm, or > having arch-specific intrinsics) > are worse than emitting plain IR (as there is no 'real' incentive to enhance > backend pattern-matching), > but arch-specific intrinsics are certainly better than inline asm. > Sorry if that thought got convoluted. Err, my main point against arch-specific intrinsics was about NOT producing them in middle-end, since nothing will know about them, and thus the IR would become more opaque if you produce them in middle-end. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D67661/new/ https://reviews.llvm.org/D67661 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
