Re: [RFC] Analysis of PR105586 and possible approaches to fix issue

[Jeff Law <jeffreyalaw@gmail.com>]

On 7/27/2022 12:58 AM, Richard Biener via Gcc wrote:
> On Tue, Jul 26, 2022 at 8:55 PM Surya Kumari Jangala via Gcc
> <gcc@gcc.gnu.org> wrote:
>> Hi,
>> I am working on PR105586. This is a -fcompare-debug failure, with the differences starting during sched1 pass. The sequence of two instructions in a basic block (block 4) is flipped with -g.
>> In addition to this, another difference is that an insn is assigned a different cycle in debug vs non-debug modes.
>> More specifically, the 2nd instruction in basic block 4 is assigned to cycle 0 w/o -g but to cycle 1 w/ -g. I felt that this could be resulting in the flipping of the later insns in the bb, so I started to investigate the difference in cycle assignment.
>>
>> In the routine schedule_block(), after scheduling an insn(schedule_insn()), prune_ready_list() is called if the ready list is not empty. This routine goes thru all the insns in the ready list and for each insn it checks if there is a state transition. If there is no state transition, then INSN_TICK(insn) is set to current_cycle+1.
>>
>> After scheduling the first insn in bb 4, when prune_ready_list() is called, we see that for the debug mode run, there is no state transition for the second insn and hence it's INSN_TICK is updated. For the non-debug run, a state transition exists and the INSN_TICK is not updated. This was resulting in the second insn being scheduled in cycle 1 in the debug mode, and in cycle 0 in the non-debug mode.
>>
>> It turned out that the initial dfa state of the basic block (‘init_state’ parameter of schedule_block()) was different in debug and non-debug modes.
>>
>> After scheduling a basic block, it’s current dfa state is copied to the fall-thru basic block. In other words, the initial dfa state of the fall thru bb is the current state of the bb that was just scheduled.
>>
>> Basic block 4 is the fall-thru bb for basic block 3. In non-debug mode, bb 3 has only a NOTE insn and hence scheduling of bb 3 is skipped. Since bb 3 is not scheduled, it’s state is not copied to bb 4. Whereas in debug mode, bb3 has a NOTE insn and a DEBUG insn. So bb 3 is “scheduled” and it’s dfa state is copied to bb4. [The dfa state of bb 3 is obtained from it’s parent bb, ie, bb 2]. Hence the initial dfa state of bb 4 is different in debug and non-debug modes due to the difference in the insns in the predecessor bb (bb 3).
>>
>> The routine no_real_insns_p() is called to check if scheduling can be skipped for a basic block. This routine checks for NOTE and LABEL insns and it returns ‘true’ if a basic block contains only NOTE/LABEL insns. Hence, any basic block which has only NOTE or LABEL insns is not scheduled.
>>
>> To fix the issue of insns being assigned different cycles, there are two possible solutions:
>>
>> 1. Modify no_real_insns_p() to treat a DEBUG insn as a non-real insn (similar to NOTE and LABEL). With this change, bb 3 will not be scheduled in the debug mode (as it contains only NOTE and DEBUG insns). If scheduling is skipped, then bb 3’s state is not copied to bb 4 and the initial dfa state of bb 4 will be same in both debug and non-debug modes
>> 2. Copy dfa state of a basic block to it’s fall-thru block only if the basic block contains ‘real’ insns (ie, it should contain at least one insn which is not a LABEL, NOTE or DEBUG). This will prevent copying of dfa state from bb 3 to bb 4 in debug mode.
> Do you know why the DFA state is not always copied to the fallthru
> destination and then copied further even if the block does not contain
> any (real) insns?  It somewhat sounds like premature optimization
> breaking things here...
Yea (premature optimization) and probably just an oversight thinking 
that a block with no real insns could be totally ignored.

jeff