This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Run the combine part of combine_and_move_insns even if -fsched-pressure
- From: Richard Sandiford <richard dot sandiford at arm dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: <gcc-patches at gcc dot gnu dot org>, <vmakarov at redhat dot com>
- Date: Wed, 07 Aug 2019 23:21:48 +0100
- Subject: Re: Run the combine part of combine_and_move_insns even if -fsched-pressure
- References: <mptimr86duk.fsf@arm.com> <20190807205737.GY31406@gate.crashing.org>
Segher Boessenkool <segher@kernel.crashing.org> writes:
> Hi Richard,
>
> On Wed, Aug 07, 2019 at 07:16:03PM +0100, Richard Sandiford wrote:
>> The main IRA routine includes the code:
>>
>> /* Don't move insns if live range shrinkage or register
>> pressure-sensitive scheduling were done because it will not
>> improve allocation but likely worsen insn scheduling. */
>> if (optimize
>> && !flag_live_range_shrinkage
>> && !(flag_sched_pressure && flag_schedule_insns))
>> combine_and_move_insns ();
>>
>> The comment about not moving insns for pressure-sensitive scheduling
>> makes sense, but I think the combine part of combine_and_move_insns is
>> still useful, since it's folding a set of an equivalent value into its
>> single user and so eliminates the need for one register altogether.
>
> During which pass are the newly combined instructions created? If not
> late, why does combine refuse to do this combination?
During if_after_combine.
I should have said, but these tests aren't actually the motivating
examples. They're just something I found while trawling the testsuite
for a nice short reproducer (gcc.c-torture/compile/scc.c).
The justification really stands independently of whichever tests end up
being bundled with the patch. While we have code to do combinations
at this point in the pipeline, I think we should use it independently
of -fsched-pressure. I'm pretty sure the current -fsched-pressure
condition was added specifically to prevent moves (which makes a lot
of sense) rather than to stop combinations too.
Thanks,
Richard