[PATCH] D50791: [SelectionDAG] unroll unsupported vector FP ops earlier to avoid libcalls on undef elements (PR38527)

Sanjay Patel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 15 12:52:08 PDT 2018


spatel added inline comments.


================
Comment at: lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp:2445
+    EVT VT = N->getValueType(0);
+    EVT WideVecVT = TLI.getTypeToTransformTo(*DAG.getContext(), VT);
+    if (TLI.isOperationExpand(N->getOpcode(), WideVecVT) &&
----------------
efriedma wrote:
> I think you need to call TLI.getRegisterType() rather than getTypeToTransformTo()?  Consider what happens to, for example, `<5 x f32>` on AArch64.
I initially didn't step through that test since it showed no diffs, but here's what I see in the debug output for that case:
VT = v5f32
WideVecVT = v8f32 (is it expected that we ask to widen to the next pow-of-2 size?)

```
Legalizing node: t12: v5f32 = fsin t11
Analyzing result type: v5f32
Widen node result 0: t12: v5f32 = fsin t11

Creating new node: t36: f32 = fsin t2
Creating new node: t37: f32 = fsin t4
Creating new node: t38: f32 = fsin t6
Creating new node: t39: f32 = fsin t8
Creating new node: t40: f32 = fsin t10
Creating new node: t41: v8f32 = BUILD_VECTOR t36, t37, t38, t39, t40, undef:f32, undef:f32, undef:f32

```

I copied the getTypeToTransformTo() call from the implementation of WidenVecRes_Unary(), so that's what we use if we fall-through. Should there be a difference in the call based on what we're using that type for (UnrollVectorOp() vs. GetWidenedVector())? 


https://reviews.llvm.org/D50791





More information about the llvm-commits mailing list