uweigand added a comment. In https://reviews.llvm.org/D53157#1305233, @kpn wrote:
> In https://reviews.llvm.org/D53157#1304347, @uweigand wrote: > > > But given that there is still infrastructure missing in the IR optimizers, > > I also think that at least in the first implementation, we probably should > > go with the original approach and just use constrained intrinsics > > everywhere in the function, and possibly add some function attribute that > > prevent any cross-inlining of functions built with constrained intrinsics > > with functions built with regular floating-point operations. > > > Subtle. This last sentence seems to imply that cross-inlining should be > allowed when there are no regular floating point operations in the function > to be inlined. This makes sense due to, for example, the common use of tiny > functions just to retrieve a value. Do I interpret your statement correctly? Sure, that would be an optimization. Another potential optimization would be to **allow** inlining, but have the inliner automatically replace regular floating-point operations with constrained intrinsics in the target routine ... But all of that is probably "stage2" after an initial implementation that just disables inlining. https://reviews.llvm.org/D53157 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
