This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Run the combine part of combine_and_move_insns even if -fsched-pressure

Segher Boessenkool <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]