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:
switch (ReductionData.getKind()) { case RK_Min: case RK_Max: case RK_UMin: case RK_UMax: cast<SelectInstruction>(ReductionRoot)->getCondition()->replaceAllUsesWith(cast<SelectInstruction>(VectorizedTree)->getCondition()); break; case RK_Arithmetic: break; }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.