On Thu, 9 Nov 2023, Maxim Kuvyrkov wrote:
> Hi Kewen, > > Below are my comments. I don't want to override Alexander's review, and if > the patch looks good to him, it's fine to ignore my concerns. > > My main concern is that this adds a new entity -- forceful skipping of > DEBUG_INSN-only basic blocks -- to the scheduler for a somewhat minor change > in behavior. Unlike NOTEs and LABELs, DEBUG_INSNs are INSNS, and there is > already quite a bit of logic in the scheduler to skip them _as part of normal > operation_. I agree with the concern. I hoped that solving the problem by skipping the BB like the (bit-rotted) debug code needs to would be a minor surgery. As things look now, it may be better to remove the non-working sched_block debug counter entirely and implement a good solution for the problem at hand. > > Would you please consider 2 ideas below. > > #1: > After a brief look, I'm guessing this part is causing the problem: > haifa-sched.cc <http://haifa-sched.cc/>:schedule_block(): > === [1] > /* Loop until all the insns in BB are scheduled. */ > while ((*current_sched_info->schedule_more_p) ()) > { > perform_replacements_new_cycle (); > do > { > start_clock_var = clock_var; > > clock_var++; > > advance_one_cycle (); As I understand, we have spurious calls to advance_one_cycle on basic block boundaries, which don't model the hardware (the CPU doesn't see BB boundaries) and cause divergence when passing through a debug-only BB which would not be present at all without -g. Since EBBs and regions may not have jump targets in the middle, advancing a cycle on BB boundaries does not seem well motivated. Can we remove it? Can we teach haifa-sched to emit RTX NOTEs with hashes of DFA states on BB boundaries with -fcompare-debug is enabled? It should make the problem readily detectable by -fcompare-debug even when scheduling did not diverge. Alexander
