[llvm] [InstCombine] Do not request non-splat vector support in code reviews (NFC) (PR #90709)

[Nikita Popov via llvm-commits]

nikic wrote:

> > Non-trivial non-splat vector handling has done significant damage to the InstCombine code base in the past (mostly due to the work of a single contributor) and I am quite wary of repeating this mistake nowadays.
> 
> I take it this is aimed at me, and I'm sorry if this has caused you problems.
> 
> Please can you give examples of the damaging combines?

Looks like not wanting to point fingers too much backfired -- I'm referring to Roman Lebedev here, who religiously implemented full non-splat vector support for every single new fold.

One specific example I remember is this one: https://github.com/llvm/llvm-project/blob/9bebf25ecbe6a8720dd581bd2a4f8d29aa763a42/llvm/lib/Transforms/InstCombine/InstCombineSelect.cpp#L1367

Modifying that kind of code is really annoying -- even if you want to do something "trivial" like supporting an additional predicate. An alternative implementation using ConstantRange utilities could handle all predicates uniformly with a lot less code -- but of course, you can't support non-splat vectors that way...

https://github.com/llvm/llvm-project/pull/90709