Re: [PATCH 2/4] sched-deps: release reg_last lists outside reg_last_in_use
Jeffrey Law <[email protected]> Mon, 3 Aug 2026 22:26:48 -0600
| Newsgroups | gmane.comp.gcc.patches |
|---|---|
| Message-ID | <[email protected]> |
On 7/30/2026 9:28 AM, [email protected] wrote: > From: Kyrylo Tkachov <[email protected]> > > reg_last_in_use does not record every reg_last entry that contains a list. > > The debug-insn path adds uses and then clears reg_pending_uses before the > normal update of reg_last_in_use. The control-use path also adds lists > without updating reg_last_in_use. free_deps only walks reg_last_in_use, so > these INSN_LIST nodes are not returned to the recycler. > > Add a teardown-only reg_last_dirty regset for these entries. Merge it into > reg_last_in_use in free_deps, then release all lists in the existing loop. > Do not use reg_last_dirty for dependence generation. Adding these entries > to reg_last_in_use during analysis would make barrier handling create new > anti-dependences for debug uses and control dependences for control uses. > > Add a selftest that puts a use list and a control-use list in a dirty-only > entry. It calls free_deps and verifies that the INSN_LIST recycler returns > both nodes. Ignoring the dirty-only entry makes this selftest fail. > > Bootstrapped and regtested on aarch64-none-linux-gnu and x86_64-linux. > > gcc/ChangeLog: > > * sched-int.h (struct deps_desc): Add reg_last_dirty. > * sched-deps.cc: Include selftest.h. > (sched_analyze_insn): Record debug-insn uses and control uses in > reg_last_dirty. > (init_deps): Initialize reg_last_dirty. > (free_deps): Merge reg_last_dirty into reg_last_in_use for teardown, > then clear it. > (selftest::test_dirty_reg_last_release): New. > (selftest::sched_deps_cc_tests): New. Provide an empty definition > when INSN_SCHEDULING is not defined. > * selftest-run-tests.cc (selftest::run_tests): Call > sched_deps_cc_tests. > * selftest.h (selftest::sched_deps_cc_tests): Declare. > > Signed-off-by: Kyrylo Tkachov <[email protected]> The selftest is a bit on the fragile side in that it's dependent on a LIFO (or nearly LIFO) implementation of the list recycling. But that's been in place since the late 90s IIRC. So probably not a terrible assumption to make for a selftest. OK for the trunk. jeff