[PATCH] D88060: [GISel]: Few InsertVecElt combines

[Jay Foad via Phabricator via llvm-commits]

foad added inline comments.


================
Comment at: llvm/lib/CodeGen/GlobalISel/CombinerHelper.cpp:2415
+  auto Index = getConstantVRegVal(MI.getOperand(3).getReg(), MRI);
+  if (!Index || *Index != (NumElts - 1))
+    return false;
----------------
arsenm wrote:
> aditya_nandakumar wrote:
> > arsenm wrote:
> > > This could start at any index? Why give up at NumElts - 1?
> > This is poorly attempting to match the highest index (assuming insert_vec_elts are found with increasing indices) so we can collect as many components as possible.
> > For eg if we traverse top down (like we currently do)
> > ```
> > a = insert_vec_elt undef, x, 0
> > b = insert_vec_elt a, y, 1
> > ```
> > We'll turn a into
> > ```
> > a = build_vector x, undef
> > b = insert_vec_elt a, y, 1
> > ```
> > Subsequently the insert_vec_elt(build_vec) combine would turn this into
> > ```
> > b = build_vector x, y
> > ```
> > 
> > Instead starting with b would give the build_vector in one shot.
> > 
> > Maybe the better option to do is check if the current insert_vec_elt is used by insert_vec_elts and bail out.
> It looks like the DAG handles this by separately canonicalizing the order of a pair of insert_vector_elts (it also seems to produce build_vector one element at a time, but I guess it makes sense to reduce the number of steps here)
> Maybe the better option to do is check if the current insert_vec_elt is used by insert_vec_elts and bail out.

Right, I think checking whether the current MI has a single use that is another eligible INSERT_VECTOR_ELT would work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88060