https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108273
Bug ID: 108273
Summary: Inconsistent dfa state between debug and non-debug
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
Test case gcc.target/powerpc/pr105586.c fails with -fcompare-debug failure on
Power10 (P10 specific) if I applied one patch to fix the current inaccurate
power10 tuning setting (which would be pushed soon).
By looking into it, I found the dfa state changes even if one basic block have
only one debug insn, but the difference on dfa states might not necessarily
cause the different choice on ready insns, it heavily depends on the context,
different cpu types result in different insns, fusion can reorder some insns
first, so this test case is fine on Power8 while not on Power10.
On Power10, at non-debug mode,
saving state for edge 2->3
// power4iu_automaton_state:8492
// power4misc_automaton_state:3
block 3 meets no_real_insns_p
saving state for edge 3->4
// power4iu_automaton_state:8492
// power4misc_automaton_state:3
at debug mode:
saving state for edge 2->3
// power4iu_automaton_state:8492
// power4misc_automaton_state:3
block 3 have only one insn which is one debug insn.
before advance_one_cycle for block 3:
// power4iu_automaton_state:8492
// power4misc_automaton_state:3
after advance_one_cycle for block 3:
// power4iu_automaton_state:8501
// power4misc_automaton_state:0
So when starting to schedule for bb 4, they have different states.
