On Fri, 17 Nov 2023, Kewen.Lin wrote: > > I don't think you can run cleanup_cfg after sched_init. I would suggest > > to put it early in schedule_insns. > > Thanks for the suggestion, I placed it at the beginning of haifa_sched_init > instead, since schedule_insns invokes haifa_sched_init, although the > calls rgn_setup_common_sched_info and rgn_setup_sched_infos are executed > ahead but they are all "setup" functions, shouldn't affect or be affected > by this placement.
I was worried because sched_init invokes df_analyze, and I'm not sure if cfg_cleanup can invalidate it. > > I suspect this may be caused by invoking cleanup_cfg too late. > > By looking into some failures, I found that although cleanup_cfg is executed > there would be still some empty blocks left, by analyzing a few failures there > are at least such cases: > 1. empty function body > 2. block holding a label for return. > 3. block without any successor. > 4. block which becomes empty after scheduling some other block. > 5. block which looks mergeable with its always successor but left. > ... > > For 1,2, there is one single successor EXIT block, I think they don't affect > state transition, for 3, it's the same. For 4, it depends on if we can have > the assumption this kind of empty block doesn't have the chance to have debug > insn (like associated debug insn should be moved along), I'm not sure. For 5, > a reduced test case is: Oh, I should have thought of cases like these, really sorry about the slip of attention, and thanks for showing a testcase for item 5. As Richard as saying in his response, cfg_cleanup cannot be a fix here. The thing to check would be changing no_real_insns_p to always return false, and see if the situation looks recoverable (if it breaks bootstrap, regtest statistics of a non-bootstrapped compiler are still informative). Alexander
