[Bug tree-optimization/113833] New: 435.gromacs fails verification on with -Ofast -march={cascadelake,icelake-server} and PGO after r14-7272-g57f611604e8bab

[Bug tree-optimization/113833] New: 435.gromacs fails verification on with -Ofast -march={cascadelake,icelake-server} and PGO after r14-7272-g57f611604e8bab

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113833

            Bug ID: 113833
           Summary: 435.gromacs fails verification on with -Ofast
                    -march={cascadelake,icelake-server} and PGO after
                    r14-7272-g57f611604e8bab
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jamborm at gcc dot gnu.org
                CC: fxue at os dot amperecomputing.com
            Blocks: 26163
  Target Milestone: ---
              Host: x86_64-linux
            Target: x86_64-linux

After r14-7272-g57f611604e8bab (Feng Xue: Do not count unused scalar
use when marking STMT_VINFO_LIVE_P [PR113091]), our runs of SPEC 2006
CPU benchmark 435.gromacs on Icelake-server CPU compiled with -Ofast
-march=native and PGO (with and without LTO) started failing with
miscompare error:

  0002:  3.07684e+02
         3.03476e+02
                   ^

I subsequently verified the failure on an Intel CascadeLake and
bisected it to the aforementioned commit.  We don't see it on our AMD
or Ampere testers (using -march=native).

I guess the miscomparison error may be well within what is expected
when using -Ofast but even in that case it would be nice to have it
documented here that that is indeed expected.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug tree-optimization/113833] 435.gromacs fails verification on with -Ofast -march={cascadelake,icelake-server} and PGO after r14-7272-g57f611604e8bab

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113833

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=60418

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
From https://www.spec.org/cpu2006/Docs/435.gromacs.html :
> The gromacs.out results shouldn't differ by more than 1.25% from the reference values.

[Bug tree-optimization/113833] 435.gromacs fails verification on with -Ofast -march={cascadelake,icelake-server} and PGO after r14-7272-g57f611604e8bab

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113833

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Looking at the past issues (which we "fixed"), makes me wonder about the spec
verification testing for gromacs and the use of -Ofast ...

[Bug tree-optimization/113833] 435.gromacs fails verification on with -Ofast -march={cascadelake,icelake-server} and PGO after r14-7272-g57f611604e8bab

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113833

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
I suspect the issue would pop up with -Ofast -fno-vect-cost-model for any
sub-architecture.  The patch referenced just adjusts costs for doing BB
vectorization (and there's reductions there as well).  It might be interesting
to offer more high-level knobs to tune for vectorization, say
-fno-vect-bb-reduction or -fforce-in-order-bb-reduction-vectorization.

A compare before/after the patch of -fopt-info-vec output might show the few
cases that are affected by the patch.

[Bug tree-optimization/113833] 435.gromacs fails verification on with -Ofast -march={cascadelake,icelake-server} and PGO after r14-7272-g57f611604e8bab

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113833

--- Comment #4 from Martin Jambor <jamborm at gcc dot gnu.org> ---
Created attachment 57397
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57397&action=edit
-fopt-info-vec before/after comparison

(In reply to Richard Biener from comment #3)
> A compare before/after the patch of -fopt-info-vec output might show the few
> cases that are affected by the patch.

I Hope I have not messed anything up.  I have added -fopt-info-vec right after
-fprofile-use into the spec config and then grepped the output for
':[^:]*:[^:]*: optimized'.  Then I sorted (because the build was parallel) and
compared the output and it seems there are quite a few *fewer* instances of
vectorization happening.

[Bug tree-optimization/113833] 435.gromacs fails verification on with -Ofast -march={cascadelake,icelake-server} and PGO after r14-7272-g57f611604e8bab

[pheeck at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113833

Filip Kastl <pheeck at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pheeck at gcc dot gnu.org

--- Comment #5 from Filip Kastl <pheeck at gcc dot gnu.org> ---
Just posting here to notify that I've found a very similar miscomparison on AMD
Zen CPUs: pr114057