This is the mail archive of the gcc-patches@gcc.gnu.org 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: PR 31396 (suboptimal register allocation)


Jan Hubicka wrote:
Hi,
Thanks for the patch. The patch is OK. You can commit it.

The analogous approach is used in IRA but on the base of IRA general cost model.

I think that factor 4 in CALLER_SAVE_PROFITABLE might be bigger than necessary because only store and load is necessary around the call (it means factor 2) and caller-saves.c frequently removes redundant load/store around calls when there are more one call in a basic block.

I've commited the patch. Quite interestingly tonight improvement in SPECfp especially with FDO bigger than I've expected http://www.suse.de/~gcctest/SPEC/CFP/sb-haydn-fdo-64-FDO/recent.html (it might be different patch comitted today too, but I don't see obvious candidate for it)

My tester also found about 1% improvement on x86_64 on SPECFP2000.

http://vmakarov.fedorapeople.org/spec/spec2000.toolbox/gcc/global-run-ratio.html
It seems that there is quite a bit of room for improvement here: the
heuristics is definitly overestimating cost of calls for long lived
pseudos.  Did you try on IRA to take into account 2)?  It looks like
load/store placement for caller save/restore is LCM problem, perhaps it
can be solved for all pseudo that might be allocated to caller saved
registers and live across call to get realistic cost estimates
beforehand?

Yes, I did LCM for pseudos got caller-saved hard registers in IRA (former file ira-calls.c). After moving the load/store, I improved the allocation by using a simple prioirity coloring algorithm to assign hard registers to pseudos got memory and conflicting with the moved pseudo-registers.

I have LCM in caller-saves.c on IRA-branch too. Although doing LCM in IRA with reassigning after that generates a bit better code than one in caller-saves.c, I removed LCM in IRA a month ago because it takes to much time (mainly rebuilding conflicts). So now LCM is done only caller-saves.c on IRA.

LCM is good to have but I don't think LCM is good to do to evaluate caller-saved hard register profitability. It is too pricey with a small improvement. In any case it is too late to be done for 4.3. As for 4.4, I am planing to submit IRA to the main line and hopefully it will be in gcc 4.4. Besides mentioned LCM, IRA (and the reload: now actually after each reload pass IRA called to improve assignment because of register spilling) has many more improvements too and I don't think it is reasonable to work on the old register allocator anymore. But of course you can do it if you want.


Vlad



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