[Bug tree-optimization/100076] eembc/automotive/basefp01 has 30.3% regression compare -O2 -ftree-vectorize with -O2 on CLX/Znver3

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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?