https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88259
--- Comment #11 from ptomsich at gcc dot gnu.org --- We have implemented vectorization support for the coupled min/max + index reduction pattern described in this PR and intend to submit it to gcc-patches shortly (probably as a multi-patch series: core support, pointer-iterator variant, plus gating and testsuite coverage). @Tamar: Since the ticket has seen no activity for some time, I would like to pick it up. Please speak up, if you are either working on this or have concerns. On motivation/impact: the vect-side support standalone fixes this PR's reproducer but, on the marian NMT decoder in SPEC CPU 2026 the hot argmax loops appear in pointer-iterator form (std::max_element over a float row). It also needs a pre-vectorizer lowering of the iterator form to an integer index reduction. With that companion work (we'll file a separate PR), the argmax pipeline is worth roughly 13% end-to-end on 772.marian_r on a modern AArch64 server core, measured against current trunk. The implementation follows the direction sketched in the earlier: - we detect the coupled pair during reduction analysis and vectorize it as a compound MINMAX_INDEX reduction kind - we keep the loop body cheap (a vector compare plus two masked selects) and resolve the winning lane's index in the epilogue (reduces the value vector with a plain min/max reduction, then extracts the matching index lane) Current state for our series as of last weekend's trunk: - the array-indexed form still does not vectorize - the pointer-iterator form vectorizes on AArch64 - first-match preserved, last-match handled via inverted select
