https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100076
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target| |x86_64-*-* CC| |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> --- See also PR90579. I wonder if there's a way to tell the CPU to not forward a load - does emitting a lfence inbetween the scalar store and the vector load fix the issue? ISTR that the "bad" effect is not so much the delay between flushing the store buffers to L1 and then loading from L1 but when the CPU speculates there's no conflicting [not forwardable] store in the store buffer and thus fetches a wrong value from L1 and thus we have to flush and restart the pipeline after we discover the conflict late? Otherwise it's really hard to address these kind of issues - for doubles and SSE vectorization we might simply vectorize all loads using scalars but that doesn't scale for larger VFs. It might eventually be enough to force peel a single iteration of all loops at the cost of code size (and performance if there's no STLF issue). That said, CPU design folks should try to address this by making the penalty smaller ;) Can you share a runtime testcase?