https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94406
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> --- Hmm, we're invoking memset from libc which might use a different path on CXL compared to Zen2? Note that a vectorized epilogue should in no way cause additional store-to-load forwarding penalties _but_ it might cause additional (positive) store-to-load forwardings. Code-generation wise the loop leaves a lot to be desired and given we know the number of iterations is 5 the vectorized epilogue will never be entered thus its overhead will only hurt. Maybe CXL branch prediction behaves better here. Note there's room for improvement in the way we dispatch to the vectorized epilogue. Exiting the main vectorized loop we do if (do_we_need_an_epilouge) { then for the vectorized epilogue we do if (remaining-niters == 1) do scalar epilogue else do vector epilogue where the complication is due to the fact that we share the scalar epilogue loops with the loop used when the runtime cost model check fails. Thus the CFG with vectorized epilogue could be more optimally structured reducing the overhead to a single jump-around. For bwaves the other improvement opportunity is to move the memset out of the full loop nest rather than just covering the innermost two loops. That probably improves register allocation.