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

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Tackling from the tuning side, -mfma -mtune=znver2 miscompares,
-mtune=generic doesn't [checkme].

Using -mfma -mtune=generic
-mtune-ctrl=^fuse_alu_and_branch,^lcp_stall,use_incdec,^avoid_false_dep_for_bmi,^one_if_conv_insn,use_ffreep,^ext_80387_constants,sse_packed_single_insn_optimal,avoid_fma_chains,avoid_fma256_chains,256_unaligned_load_optimal,256_unaligned_store_optimal,^qimode_math
(all tunables to the znver2 variant) doesn't miscompare

on the gimple side IVOPTs and avoid_fma_chains makes a difference

-O2 -mfma -mtune=generic -fno-schedule-insns2 is OK
-O2 -mfma -mtune=znver2 -fno-schedule-insns2 -mtune-ctrl=^avoid_fma_chains
FAILs
-O2 -mfma -mtune=znver2 -fno-schedule-insns2 -mtune-ctrl=^avoid_fma_chains
-fno-ivopts is OK
-O2 -mfma -mtune=znver2 -fno-schedule-insns2 -fno-ivopts is OK
-O2 -mfma -mtune=znver2 -fno-ivopts is OK

Trying to bisect with IVOPTs debug-counter.

65:69 FAIL
65:66 OK
67:69 OK

*sigh*

more complex "ranges" for debug counters appreciated,
-fdbg-cnt=foo:{5-6,9,1-10} or some sorts of that (lists of ranges / values).
I'm definitely missing a all-but-N as well. ~6 and ~6-9 maybe.  Guess
{} don't work very well due to shell limitations so maybe
simply foo:5-6:9:1-10,bar:... with changing semantics of previous handling.
Implementation-wise we'd have instead of high/low arrays
an array of pair<counter, vec<pair<high, low> > which we only look at
the last element of the vec (sort it backwards), popping it whenever
we reach it's max and checking against the current min.  or some
other data structure mimicing this, that is, dbg_cnt () is still O(1)
just parsing the option might involve sorting.

Reply via email to