[PATCH] D30086: Add generic IR vector reductions

Elena Demikhovsky via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Feb 18 23:15:41 PST 2017


delena added a comment.

According to the code that I see, all reduction intrinsics have the same form and the same handling.
IMO, llvm.vector.reduce(<metadata>, <vector>) would cover all aspects of FP modes, and integer signed-unsigned variants.
The <metadata> class can include opcode and "properties".
I know that it was discussed earlier, but another option is providing the full set for FP and the full set for integers - all *SInt* and *UInt* variants.

I don't think that providing FP properties as additional boolean parameters is a good solution.



================
Comment at: docs/LangRef.rst:11655
+reduction of a vector, returning the result as a scalar. The return type matches
+the element-type of the vector input.
+
----------------
mehdi_amini wrote:
> I think it'd be important to clarify the ordering: do we require a "fast" FMF to change it? If not, why?
I think that in the case of FP operations we need two intrinsics - "ordered" and "fast".


================
Comment at: docs/LangRef.rst:11832
+element-type of the vector input.
+
 Half Precision Floating Point Intrinsics
----------------
Usually, we give code examples in the documentation.


================
Comment at: include/llvm/Analysis/TargetTransformInfo.h:715
+  /// the intrinsics form instead of the shuffle form.
+  bool useReductionIntrinsic(unsigned Opcode, Type *Ty, bool IsMaxOp = false,
+                             bool IsSigned = false, bool NoNaN = false) const;
----------------
What does IsMaxOp mean? I think that it is better to split this interface into several functions and do not mix fp and integers together.


Repository:
  rL LLVM

https://reviews.llvm.org/D30086





More information about the llvm-commits mailing list