From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeffrey A Law <law@hurl.cygnus.com>
To: egcs@cygnus.com
Subject: Re: Reload patch to improve 386 code
Date: Mon, 18 Aug 1997 19:09:07 -0000
Message-ID: <199708181855.OAA03711@jenolan.rutgers.edu>
In-reply-to: Reload patch to improve 386 code
X-SW-Source: 1997-08/0107.html
Message-ID: <19970818190907.ZxKByeA8-bxzcPTcdTtR67R5e9h6Pwl7RykS_aFRR68@z>

  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.

jeff