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