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

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri accepted this revision.
lebedev.ri added a comment.

LG for now.

In D76623#1944788 <https://reviews.llvm.org/D76623#1944788>, @spatel wrote:

> 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


Yes, that is the general idea, if we have insert-of-one-use-extract
(or, all uses are inserts into same lane?), try to make extraction
to be from the same lane. Though there is a second potential fold here:
start from `extractelement`, and try to minimize it's cost by moving it into lower lanes.

It does sound involved, i'm not sure if it will be worth it in the end.


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

https://reviews.llvm.org/D76623