I noticed that we could miscompile reductions while working on the recent 2-way enhancements.
The problem appears to be limited to cases where a min/max reduction has extra uses of the compare operand to the select.
I assume that the existing test in used-reduced-op.ll also shows a miscompile, but nobody noticed in such a large test?
I don't think you need matches here. You can rely on ReductionData.getKind() and then just do something like this:
And even better to create a new member function in Operation data, which will replace all uses for the vectorized instruction like in this code + the final replacement.