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

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Sep 29 07:45:28 PDT 2020


arsenm added inline comments.


================
Comment at: llvm/lib/CodeGen/GlobalISel/CombinerHelper.cpp:2470
+  };
+  for (unsigned I = 0; I < MatchInfo.size(); ++I)
+    if (!MatchInfo[I].isValid())
----------------
Braces


================
Comment at: llvm/lib/CodeGen/GlobalISel/CombinerHelper.cpp:2415
+  auto Index = getConstantVRegVal(MI.getOperand(3).getReg(), MRI);
+  if (!Index || *Index != (NumElts - 1))
+    return false;
----------------
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)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88060



More information about the llvm-commits mailing list