Re: [IRA] Query about improve_allocation() routine in IRA
On 4/19/23 14:53, Surya Kumari Jangala wrote: ... I have a few queries: 1. A zero cost seems strange for the regs r14-r31. If using a reg in the set [14..31] has zero cost, then why wasn’t such a reg chosen for r118 in the first place, instead of r3? I guess it is because assign_hard_reg (see also calculate_saved_nregs) takes into account that r31 not used yet needs insns to save/restore it in prolog/epilog when we assign r31 the first time to any pseudos. All pseudos assigned to r31 after that will not be punished. It is not reflected in the hard reg costs as we do not know will be this hard register assigned. Also an order of hard register assignment can be used for some targets. It works when all assignment costs are the same. 2. In step 3, shouldn’t we restrict the register chosen to be a register that has been assigned to a conflicting allocno? This is not the case for the failing test. The allocno for r118 is assigned r31, but there is no conflicting allocno that has been assigned r31. Yes in this case, this approach could be used. But what if after spilling conflicting pseudos for one pseudo, we can simply use hard registers of the pseudos spilled before for free for another pseudo conflicting with the spilled pseudos. So I think we should constrain to any hard regs used before improve_allocation, whether they are used by conflicting pseudos or not. 3. In steps 1 & 2, shouldn’t we consider the register save and restore cost too? ’r31’ being a callee-save (non-volatile) register has to be saved before being used, whereas this is not required for r3 which is a caller-save (volatile) register. I guess we could. I am not against improving the code. Especially as IRA was developed for many years. For example cost calculations in assign_hard_reg were improved before and after adding improve_allocation and it might make some parts of code are less important. But any new change would be nice to be proved by benchmarking (SPEC rates or size or executed spilled insns etc). When improve_allocation was added, it improved SPEC2000 for x86 but I don't remember by what margin. Thank you for reporting this case and your questions, proposals and interest in RA. I am open to review your patches for RA.
Re: Second GCC 13.1 Release Candidate available from gcc.gnu.org
I tried the RC 2 on powerpc64 both BE and LE and on power 7 through 10 and saw nothing unexpected. On 4/19/23 8:39 AM, Jakub Jelinek via Gcc wrote: The second release candidate for GCC 13.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/13.1.0-RC2-20230419/ ftp://gcc.gnu.org/pub/gcc/snapshots/13.1.0-RC2-20230419/ and shortly its mirrors. It has been generated from git commit r13-7226-g68997d4323cdcb. The https://gcc.gnu.org/PR108969 fix didn't work out as intended, so we had to revert the changes. Please don't use the first GCC 13.1 release candidate for anything, it contains symbols 13.1 final release will not contain. I have so far bootstrapped and tested the release candidate on x86_64-linux. Please test it and report any issues to bugzilla. If all goes well, we'd still like to release 13.1 on Wednesday, April 26th.
gcc-11-20230420 is now available
Snapshot gcc-11-20230420 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20230420/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision e98ffbc7fd2129edea527061baa0546325474e9d You'll find: gcc-11-20230420.tar.xz Complete GCC SHA256=d50f8f63d734cf3bbdf596a44640572a47426d7757f3ab01f649577fcb70d11d SHA1=9b416f72634c6ca50952e10e65f15d97da639cfc Diffs from 11-20230414 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Second GCC 13.1 Release Candidate available from gcc.gnu.org
About gcc-13.1.0-RC2-20230419: I compiled gcc-13.1.0-RC2-20230419 and all went well. Running make -k check produced: = mpc 1.2.1: tests/test-suite.log = # TOTAL: 69 # PASS: 68 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: tmul == Error, mpc_mul returns an out-of-range exponent: 0.1001011010100010101010010110111110110E-1085!!! $ /home/sidney/gcc/gcc-13.1.0-RC2-20230419/mpfr/configure --srcdir=../../gcc-1 3.1.0-RC2-20230419/mpfr --cache-file=./config.cache --prefix=/usr/local/gcc-13.1 .0-RC2-20230419 --enable-languages=c,c++,fortran,lto,objc --program-transform-na me=s,y,y, --disable-option-checking --build=x86_64-pc-linux-gnu --host=x86_64-pc -linux-gnu --target=x86_64-pc-linux-gnu --with-build-libsubdir=. --disable-share d --with-gmp-include=/home/sidney/gcc/obj-13.1.0-RC2-20230419/./gmp --with-gmp-l ib=/home/sidney/gcc/obj-13.1.0-RC2-20230419/./gmp/.libs --Sidney Marshall
