[PATCH] D127115: [RFC][DAGCombine] Make sure combined nodes are added back to the worklist in topological order.
Simon Pilgrim via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jun 28 05:14:09 PDT 2022
RKSimon added inline comments.
================
Comment at: llvm/test/CodeGen/X86/vselect-constants.ll:309
; AVX-NEXT: vmovd %xmm0, %eax
; AVX-NEXT: retq
%true_true = icmp ne <2 x i16> %x, zeroinitializer
----------------
deadalnix wrote:
> RKSimon wrote:
> > Not sure what to do about this one. We end up with a 'vector_shuffle<0,4,u,u,u,u,u,u>' that won't easily fold away. Elt 4 is known zero, so we could try to convert this into an AND, but my shuffle combine attempts to do that in the past have always caused a lot of regressions.
> > ```
> > SelectionDAG has 29 nodes:
> > t0: ch = EntryToken
> > t2: v8i16,ch = CopyFromReg t0, Register:v8i16 %0
> > t28: v8i16 = BUILD_VECTOR Constant:i16<0>, Constant:i16<0>, undef:i16, undef:i16, undef:i16, undef:i16, undef:i16, undef:i16
> > t49: v8i16 = setcc t2, t28, setne:ch
> > t55: v2i64 = any_extend_vector_inreg t49
> > t26: v2i64 = BUILD_VECTOR Constant:i64<1>, Constant:i64<0>
> > t33: v2i64 = and t55, t26
> > t52: v8i16 = bitcast t33
> > t58: v8i16 = vector_shuffle<0,4,u,u,u,u,u,u> t52, undef:v8i16
> > t48: v8i16 = sign_extend_inreg t58, ValueType:ch:v8i1
> > t29: v8i16 = BUILD_VECTOR Constant:i16<2>, Constant:i16<0>, undef:i16, undef:i16, undef:i16, undef:i16, undef:i16, undef:i16
> > t30: v8i16 = BUILD_VECTOR Constant:i16<1>, Constant:i16<0>, undef:i16, undef:i16, undef:i16, undef:i16, undef:i16, undef:i16
> > t36: v8i16 = vselect t48, t29, t30
> > t37: v4i32 = bitcast t36
> > t38: i32 = extract_vector_elt t37, Constant:i64<0>
> > t21: ch,glue = CopyToReg t0, Register:i32 $eax, t38
> > t22: ch = X86ISD::RET_FLAG t21, TargetConstant:i32<0>, Register:i32 $eax, t21:1
> > ```
> Do you have an example of such a change you can point me to?
(sorry busy with other stuff so can't do much llvm work atm).
I started looking at adding a fold to DAGCombiner::visitVECTOR_SHUFFLE that would determine if all the non-inplace shuffle elements were known zero elements (tested with SelectionDAG::MaskedVectorIsZero) - and if so replaced it with a AND node - that node could be later folded by DAGCombiner::XformToShuffleWithZero which could then convert back to a 'clear mask' if it was legal. That might be a good place to start investigation.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D127115/new/
https://reviews.llvm.org/D127115
More information about the llvm-commits
mailing list