arsenm wrote: > > > * 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? > > Isn't the condition in code in terms of VecIn.size() == 2? I believe that > VecIn is the _unique_ input elements, right? Which is distinct from the > number of elements in the destination type? (Am I just misreading? I only > skimmed this.)
> > > > 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. > > Honestly, #122671 (from the review description only) sounds like a worthwhile > change. That's not a hugely compelling argument here. Let's settle the prior > point, and then return to this. If I'm just misreading something, let's not > waste time discussing this. 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
