https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357
--- Comment #9 from Tamar Christina <tnfchris at gcc dot gnu.org> --- (In reply to Richard Biener from comment #8) > The following fixes this. I'm not 100% convinced but it does seem "obvious" > (but for the "peeled" case we seem to eventually create duplicate COND > reduction IVs? But possibly we reject this case anyhow). I'm testing this > now. > It looks obvious to me too and I guess I had just missed it during the removal of the explicit loop_exits. The duplicate reduction comes from that for the PEELED case we still have a separate BB for the main and "early" exit. For the PEELED case we treated all exits as being early but in the CFG they aren't. I think we could fix this by in slpeel_tree_duplicate_loop_to_edge_cfg when "peeled" point every exit, including the main one to the same block. Then in vectorizable_live_operations and friends we can remove the special casing for LOOP_VINFO_EARLY_BREAKS_VECT_PEELED since the codegening the first exit would cover all exits. Which would remove the duplicate reduction calculation.
