Re: PR 31396 (suboptimal register allocation)

["Daniel Berlin" <dberlin at dberlin dot org>]

On Jan 17, 2008 10:41 AM, Vladimir Makarov <vmakarov@redhat.com> wrote:
> 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.
LCM also has a very theoretical model of optimality that doesn't work
out so well in practice.

>  It is too pricey with a small
> improvement.

There are non-edge based formulations that are *much* faster to
calculate (at least in dataflow), but i'm still not sure it is worth
the cost of calculating (since it will give you the same
answers/improvements)