[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