> On Oct 7, 2016, at 6:08 PM, Pat Haugen <pthau...@linux.vnet.ibm.com> wrote:
> The patch here, https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01872.html,
> attempted to scale down the register limit used by -fsched-pressure for the
> case where the block in question executes as frequently as the entry block to
> just the call_clobbered (i.e. call_used) regs. But the code is actually
> scaling toward call_saved registers. The following patch corrects that by
> computing call_saved regs per class and subtracting out some scaled portion
> of that.
> Bootstrap/regtest on powerpc64le with no new failures. Ok for trunk?
I stared at your patch and current code for good 30 minutes, and I still don't
see what is wrong with the current code.
With your patch the number of registers from class CL that scheduler has at its
disposal for a single-basic-block function will be:
sched_call_regs_num[CL] = ira_class_hard_regs_num[CL] - call_saved_regs_num[CL];
where call_saved_regs_num is number of registers in class CL that need to be
saved in the prologue (i.e., "free" registers). I can see some logic in setting
sched_call_regs_num[CL] = call_saved_regs_num[CL];
but not in subtracting number of such registers from the number of total
available hard registers.
Am I missing something?
Also, could you share the testcase that you used to investigate the problem
with register-aware scheduling? I wonder if there is a problem lurking.
> 2016-10-07 Pat Haugen <pthau...@us.ibm.com>
> * haifa-sched.c call_used_regs_num: Rename to...
> call_saved_regs_num: ...this.
> (sched_pressure_start_bb): Scale call_saved regs not call_used.
> (alloc_global_sched_pressure_data): Compute call_saved regs.