arsenm wrote: > I don't think the heuristic here is quite what you want. I believe this > heuristic disables both of the following cases: > > * BuildVector w/one non-zero non-undef element > * BuildVector w/one non-zero non-undef source, repeated 100 times (i.e. splat > or select of two splats) > > Disabling the former seems defensible, doing so for the second less so.
Depends if isExtractVecEltCheap is true or not for the non-zero index. > * BuildVector w/one non-zero non-undef source, repeated 100 times (i.e. splat > or select of two splats) I don't follow, this is a 2 element vector, how can you have 100 variants? > If the target isn't optimally lowering the splat or select of splat case in > the shuffle lowering, maybe we should just adjust the target lowering to do > so?t It's not a lowering issue, it's the effect on every other combine. We'd have to special case 1 element + 1 undef shuffles everywhere we handle extract_vector_elt now, which is just excessive complexity. #122671 is almost an alternative in one instance, but still shows expanding complexity of handling this edge case. https://github.com/llvm/llvm-project/pull/122672 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
