[Bug rtl-optimization/108273] New: Inconsistent dfa state between debug and non-debug

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

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.