[PATCH] D76623: [VectorCombine] try to form a better extractelement

[Sanjay Patel via Phabricator via llvm-commits]

spatel added a comment.

In D76623#1944608 <https://reviews.llvm.org/D76623#1944608>, @lebedev.ri wrote:

> While this looks good in principle, i'm starting to have second thoughts about the general design here..
>
> Since this doesn't affect the calculated cost, i wonder if it would be better to go more generic,
>  and instead implement some kind of lane reordering?


Hmm...I'm not seeing what a more generic solution would look like. Do you have an example/suggestion?
If we implement the larger match that starts from an insertelement, I'm imagining this becomes something like InstCombine's canEvaluateZExtd() or AggressiveInstCombine's TruncInstCombine. So we have:
insertelement (some string of scalar ops that are seeded by extractelement and/or constants) --> series of vector ops with extract/insert removed
We could build that up in steps, so start with the simplest case of: insert undef, (binop (extract X), C) --> vector binop X, vecC


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

https://reviews.llvm.org/D76623