[Bug rtl-optimization/90174] Bad register spill due to top-down allocation order

[Bug rtl-optimization/90174] Bad register spill due to top-down allocation order

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90174

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tnfchris at gcc dot gnu.org

--- Comment #10 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Hi Vlad,

Just curious if you had a chance to think about an approach to this that would
be acceptable.

[Bug rtl-optimization/90174] Bad register spill due to top-down allocation order

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90174

--- Comment #11 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Tamar Christina from comment #10)
> Hi Vlad,
> 
> Just curious if you had a chance to think about an approach to this that
> would be acceptable.

  Sorry for not working on this issue more although I thought about the problem
for some time w/o finding any possible small code changes could solve the
problem.

  I just expressed my point of view to the bottom-up approach.  If somebody
implements any new RA approach which at least does not hurt credible benchmarks
(e.g. SPEC) and improve some benchmarks and does not complicate existing RA too
much, nobody will have legitimate arguments not to include the new code into
GCC.

  I think that may be for some cases bottom-up approach could work better. 
Probably this is code for number crunching (with a lot of loop iterations). 
For some cases top-down approach works better for loops with smaller number
iterations  (e.g. most loops in GCC itself).

  Simply, I tried already bottom-up approach and don't want to work on this
again because if it does not work I will have to throw this work off again.

  I am mostly in maintenance mode for GCC RA, don't want to work on big RA
changes.  This work would be also very hard to sell to my management.

  If somebody implements bottom-up RA as an optional (or default if it is
better on SPEC) algorithm and this improves some benchmarks, I will not object.
 The work I think would take several months for a person familiar with RA.

[Bug rtl-optimization/90174] Bad register spill due to top-down allocation order

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90174

--- Comment #12 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Vladimir Makarov from comment #11)
> (In reply to Tamar Christina from comment #10)
> > Hi Vlad,
> > 
> > Just curious if you had a chance to think about an approach to this that
> > would be acceptable.
> 
>   Sorry for not working on this issue more although I thought about the
> problem for some time w/o finding any possible small code changes could
> solve the problem.
> 

Ah, hmm that's too bad but thanks for looking into it!

>   I just expressed my point of view to the bottom-up approach.  If somebody
> implements any new RA approach which at least does not hurt credible
> benchmarks (e.g. SPEC) and improve some benchmarks and does not complicate
> existing RA too much, nobody will have legitimate arguments not to include
> the new code into GCC.
> 
>   I think that may be for some cases bottom-up approach could work better. 
> Probably this is code for number crunching (with a lot of loop iterations). 
> For some cases top-down approach works better for loops with smaller number
> iterations  (e.g. most loops in GCC itself).
> 

I don't know much about the current RA implementation, but would it be possible
you think to have this be heuristics driven? or do you think it would be too
expensive to try multiple strategies and keep the one that works best?

[Bug rtl-optimization/90174] Bad register spill due to top-down allocation order

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90174

--- Comment #13 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Tamar Christina from comment #12)
> (In reply to Vladimir Makarov from comment #11)
> >   I just expressed my point of view to the bottom-up approach.  If somebody
> > implements any new RA approach which at least does not hurt credible
> > benchmarks (e.g. SPEC) and improve some benchmarks and does not complicate
> > existing RA too much, nobody will have legitimate arguments not to include
> > the new code into GCC.
> > 
> >   I think that may be for some cases bottom-up approach could work better. 
> > Probably this is code for number crunching (with a lot of loop iterations). 
> > For some cases top-down approach works better for loops with smaller number
> > iterations  (e.g. most loops in GCC itself).
> > 
> 
> I don't know much about the current RA implementation, but would it be
> possible you think to have this be heuristics driven? or do you think it
> would be too expensive to try multiple strategies and keep the one that
> works best?

Probably trying multiple strategies will be too expensive.  Also compile-time
evaluation of allocation cost is not that accurate, especially taking into
account that the local register allocator can change global RA decisions and
the changes are unpredictable.

  If the top-down algorithm works better for some cases, we could get some
experience when it works and try to find heuristics to choose the right
algorithm.  I think it would be more realistic approach.  It sounds like a case
for ML but I am sure ML will not work.  It is not a smooth function, besides ML
create a lot of problems with GCC building (benchmark set, costly building,
valdiation and using ML model etc).  So heuristics built on understanding is a
way to go.  But I speculated too much because there is no bottom-up RA
implementation with finding its advantages (if there are any) and its
disadvantages.