Yeah, In the test it's reasonable, just used one extra register. I'm currently running some benchmarks to make sure those are OK too.
Regards, Tamar ________________________________________ From: Bin.Cheng <amker.ch...@gmail.com> Sent: Friday, October 28, 2016 12:38:28 PM To: Tamar Christina Cc: Pat Haugen; Maxim Kuvyrkov; GCC Patches; nd Subject: Re: [PATCH] Fix computation of register limit for -fsched-pressure On Fri, Oct 28, 2016 at 12:27 PM, Tamar Christina <tamar.christ...@arm.com> wrote: > Looking at it again, > > it seems to be that the testcase should be adjusted. > There's no actual spilling. It just uses more registers than before due to > the scheduling. Sorry I didn't look into the test, but using more registers sounds like a regression too? At least we need to make sure it's reasonable. Thanks, bin > > I will update the testcase. > > Thanks. > > ________________________________________ > From: gcc-patches-ow...@gcc.gnu.org <gcc-patches-ow...@gcc.gnu.org> on behalf > of Tamar Christina <tamar.christ...@arm.com> > Sent: Friday, October 28, 2016 10:53:20 AM > To: Pat Haugen; Maxim Kuvyrkov > Cc: GCC Patches; nd > Subject: Re: [PATCH] Fix computation of register limit for -fsched-pressure > > Forwarding to list as well. > ________________________________________ > From: Tamar Christina > Sent: Friday, October 28, 2016 10:52:17 AM > To: Pat Haugen; Maxim Kuvyrkov > Cc: GCC Patches > Subject: Re: [PATCH] Fix computation of register limit for -fsched-pressure > > Hi Pat, > > The commit seems to be causing some odd stack spills on aarch64. > > I've created a new ticket https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78142 > > Thanks, > Tamar > > ________________________________________ > From: gcc-patches-ow...@gcc.gnu.org <gcc-patches-ow...@gcc.gnu.org> on behalf > of Pat Haugen <pthau...@linux.vnet.ibm.com> > Sent: Tuesday, October 18, 2016 4:07:55 PM > To: Maxim Kuvyrkov > Cc: GCC Patches > Subject: Re: [PATCH] Fix computation of register limit for -fsched-pressure > > On 10/18/2016 05:31 AM, Maxim Kuvyrkov wrote: >>> > I see your point and agree that current code isn't optimal. However, I >>> > don't think your patch is accurate either. Consider >>> > https://gcc.gnu.org/onlinedocs/gccint/Register-Basics.html and let's >>> > assume that FIXED_REGISTERS in class CL is set for a third of the >>> > registers, and CALL_USED_REGISTERS is set to "1" for another third of >>> > registers. So we have a third available for zero-cost allocation >>> > (CALL_USED_REGISTERS-FIXED_REGISTERS), a third available for spill-cost >>> > allocation (ALL_REGISTERS-CALL_USED_REGISTERS) and a third non-available >>> > (FIXED_REGISTERS). >>> > >>> > For a non-loop-single-basic-block function we should be targeting only >>> > the third of register available at zero-cost -- correct? > Yes. > > This is what is done by the current code, but, apparently, by accident. It > seems that the right register count can be obtained with: >>> > >>> > for (int i = 0; i < ira_class_hard_regs_num[cl]; ++i) >>> > - if (call_used_regs[ira_class_hard_regs[cl][i]]) >>> > - ++call_used_regs_num[cl]; >>> > + if (!call_used_regs[ira_class_hard_regs[cl][i]] >>> > + || fixed_regs[ira_class_hard_regs[cl][i]]) >>> > + ++call_saved_regs_num[cl]; >>> > >>> > Does this look correct to you? >> Thinking some more, it seems like fixed_regs should not be available to the >> scheduler no matter what. Therefore, the number of fixed registers should >> be subtracted from ira_class_hard_regs_num[cl] without any scaling >> (entry_freq / bb_freq). > > Ahh, yes, I forgot about FIXED_REGISTERS being included in > CALL_USED_REGISTERS. I agree they should be totally removed from the register > limit calculation. I'll rework the patch. > > Thanks, > Pat >
