RE: [PATCH 1/2] Use NO_REGS in cost calculation when the preferred register class are not known yet.

[Liu, Hongtao via Gcc-patches]

> -----Original Message-----
> From: Vladimir Makarov <vmaka...@redhat.com>
> Sent: Saturday, April 22, 2023 3:26 AM
> To: Liu, Hongtao <hongtao....@intel.com>; gcc-patches@gcc.gnu.org
> Cc: crazy...@gmail.com; hjl.to...@gmail.com
> Subject: Re: [PATCH 1/2] Use NO_REGS in cost calculation when the
> preferred register class are not known yet.
> 
> 
> On 4/19/23 20:46, liuhongt via Gcc-patches wrote:
> > 1547  /* If this insn loads a parameter from its stack slot, then it
> > 1548     represents a savings, rather than a cost, if the parameter is
> > 1549     stored in memory.  Record this fact.
> > 1550
> > 1551     Similarly if we're loading other constants from memory (constant
> > 1552     pool, TOC references, small data areas, etc) and this is the only
> > 1553     assignment to the destination pseudo.
> >
> > At that time, preferred regclass is unknown, and GENERAL_REGS is used
> > to record memory move cost, but it's not accurate especially for large
> > vector modes, i.e. 512-bit vector in x86 which would most probably
> > allocate with SSE_REGS instead of GENERAL_REGS. Using GENERAL_REGS
> > here will overestimate the cost of this load and make RA propagate the
> > memeory operand into many consume instructions which causes worse
> performance.
> 
> For this case GENERAL_REGS was used in GCC practically all the time. You can
> check this in the old regclass.c file (existing until IRA introduction).
> 
> But I guess it is ok to use NO_REGS for this to promote more usage of
> registers instead of equiv memory and as a lot of code was changed since
> then (the old versions of GCC even did not support vector regs).
> 
> Although it would be nice to do some benchmarking (SPEC is preferable) for
> such kind of changes.
Thanks, I've run SPEC2017 on x86 ICX, no big performance change, a little bit 
code size improvement as expected(codesize of 1 load + multi ops should be 
smaller than multi ciscy ops).  
> 
> On the other hand, I expect that any performance regression (if any) will be
> reported anyway.
> 
> The patch is ok for me.  You can commit it into the trunk.
> 
> Thank you for addressing this issue.
> 
> > Fortunately, NO_REGS is used to record the best scenario, so the patch
> > uses NO_REGS instead of GENERAL_REGS here, it could help RA in
> PR108707.
> >
> > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,} and
> > aarch64-linux-gnu.
> > Ok for trunk?
> >
> > gcc/ChangeLog:
> >
> >     PR rtl-optimization/108707
> >     * ira-costs.cc (scan_one_insn): Use NO_REGS instead of
> >     GENERAL_REGS when preferred reg_class is not known.
> >
> > gcc/testsuite/ChangeLog:
> >
> >     * gcc.target/i386/pr108707.c: New test.