From mboxrd@z Thu Jan  1 00:00:00 1970
From: Joern Rennecke <amylaar@cygnus.co.uk>
To: egcs@cygnus.com
Subject: Re: Reload patch to improve 386 code
Date: Mon, 18 Aug 1997 20:46:06 -0000
Message-id: <199708182009.VAA22875@phal.cygnus.co.uk>
In-reply-to: 1521.871931347@hurl.cygnus.com
X-SW-Source: 1997-08/0109.html

> 
>   In message <199708181855.OAA03711@jenolan.rutgers.edu>you write:
>   > Before this leaves my head, I wanted to point something out which
>   > you've reminded me of.  When the scheduler (this applies to both the
>   > original and Haifa versions equally) becomes aggressive, it produces a
>   > large number of reloads in certain situations.  Reloads which would
>   > not have happened if scheduling did not take place.  This happens
>   > especially if register pressure is high already.  I noticed this
>   > particularly on RISC platforms, seems in this case the more registers
>   > available the worse things became when the register usage was
>   > saturated.
> Yup.  Absolutely.  This is a known issue with schedulers in general;
> you can see this in action if you look at fpppp in spec.
> 
> The haifa scheduler has some code to "prefer" schedules which don't
> lengthen register lifetimes, but I don't know how effective it really
> is.  The normal scheduler has some code to do this too, but it's less
> effective than haifa.
> 
> However, I've done experiments and the more I make the scheduler
> try to reduce register lifetimes, the worse _overall_ performance I
> see.
> 
> It almost makes me think such code should be dependent on the number
> of registers actually in the code -- ie once the ratio of pseudos
> to hard registers hits some magic point, the code to shorten lifetimes
> kicks in and tries to keep the scheduler from extending register
> lifetimes.

I think we could get better results if the scheduler just does its work,
but leaves enough information for reload so that reload can do un-do some
aggressive scheduling if this saves some reloads and these savings
outweigh the penalty for sub-optimal scheduling.

In a similar vein, it would be useful if regmove could pass some information
of the transformation it has done down to reload.  If some value ends up in
a stack slot, some of the regmove transformation would better be undone.