[PATCH] D69339: [SelectionDAG] Add support for FP_ROUND in WidenVectorOperand.

[Craig Topper via Phabricator via llvm-commits]

craig.topper added inline comments.


================
Comment at: llvm/test/CodeGen/AMDGPU/fptrunc.ll:34
+; FUNC-LABEL: {{^}}fptrunc_v3f64_to_v3f32:
+; GCN: v_cvt_f32_f64_e32
+; GCN: v_cvt_f32_f64_e32
----------------
foad wrote:
> arsenm wrote:
> > foad wrote:
> > > craig.topper wrote:
> > > > Is this hitting the unrolling path rather than any of the code that creates a wider node?
> > > The test definitely fails without the fix above, but I haven't looked in detail at how it is handled.
> > I would expect this to hit the unroll path. v3f64 isn't legal
> If I'm reading the legalize-types debug output correctly it is being widened to v4 and then split to v2:
> ```
> Legalizing node: t33: v3f32 = fp_round t30, TargetConstant:i64<0>
> Analyzing result type: v3f32
> Legal result type
> Analyzing operand: t30: v3f64 = extract_subvector t37, Constant:i32<0>
> Widen node operand 0: t33: v3f32 = fp_round t30, TargetConstant:i64<0>
> 
> Legalizing node: t49: v4f32 = fp_round t37, TargetConstant:i64<0>
> Analyzing result type: v4f32
> Legal result type
> Analyzing operand: t37: v4f64 = bitcast t36
> Split node operand: t49: v4f32 = fp_round t37, TargetConstant:i64<0>
> ```
> Is that a problem? Is my patch still OK?
Ok so v4f32 result type is legal so it went up to v4f32 <- v4f64, but then v4f64 isn't legal so it split back down? I think that should be fine. But maybe @arsenm should confirm.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69339/new/

https://reviews.llvm.org/D69339