farzonl wrote: > Please create a separate RFC for these intrinsics. I don't think there is a > consensus on these intrinsics, and > https://discourse.llvm.org/t/rfc-all-the-math-intrinsics/78294 covers way too > much disparate ground (something like "tan" and something like "dot" are > entirely separate categories, _especially_ if you also want to include > integer intrinsics).
@nikic The dot case was discussed pretty heavily in the rfc. Would you be open to moving forward if we drop the integer dot intrinsic as a target opcode, but keep the float dot product? We will also put an RFC together for the integer dot intrinsic cases. @SamTebbs33 For us using an intrisnic better for the float case because you can of specifying rounding modes via vecreduce. I don't believe `vecreduce.add(mul(zext, zext))` can do that. At least I don't know how you could but that's a trivial prospect for intrinsics\constraint intrinsics. Also we are coming at this from different use cases. We want to support language features for now that will be HLSL, but maybe later that includes c++ 20s `std::inner_product`. A higher level intrinsic that is accessible from clang for us is really nice. So this isn't an optimization for us that the vectorizer detects but our basic lowering. https://github.com/llvm/llvm-project/pull/102872 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
