public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <199708181855.OAA03711@jenolan.rutgers.edu> (raw)
Message-ID: <19970818190907.ZxKByeA8-bxzcPTcdTtR67R5e9h6Pwl7RykS_aFRR68@z> (raw)
In-Reply-To: Reload patch to improve 386 code

  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

             reply	other threads:[~1997-08-18 19:09 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-08-18 18:55 David S. Miller [this message]
1997-08-18 19:09 ` Jeffrey A Law
     [not found] <Pine.SOL.3.90.970819095143.291G-100000@starsky.informatik.rwth-aachen.de>
1998-09-04  5:03 ` Jeffrey A Law
1998-09-04  5:05   ` Bernd Schmidt
1998-09-04 22:36     ` Joern Rennecke
1998-09-05  4:45     ` Jeffrey A Law
1998-09-05 15:49       ` Joern Rennecke
1998-09-05 15:44         ` Jeffrey A Law
1998-09-06  1:09           ` Mark Mitchell
1998-09-06  1:09             ` Jeffrey A Law
1998-09-07  9:48       ` Bernd Schmidt
1998-09-07 19:09         ` Joern Rennecke
1998-09-07 18:26           ` Jeffrey A Law
1998-09-07 19:09         ` Jeffrey A Law
1998-09-04 21:38   ` Joern Rennecke
1998-09-04 21:38     ` Jeffrey A Law
  -- strict thread matches above, loose matches on Subject: below --
1997-08-21 16:51 Problems on PowerPC David Edelsohn
1997-08-21 17:37 ` Reload patch to improve 386 code Bernd Schmidt
1997-08-21 16:51 Joern Rennecke
1997-08-21 15:20 egcs repository Joel Sherrill
1997-08-21 15:47 ` Reload patch to improve 386 code Bernd Schmidt
1997-08-19 19:00 Joern Rennecke
1997-08-19  8:50 Jakub Jelinek
1997-08-19  7:36 egcs: A new compiler project to merge the existing GCC forks (fwd) Robert Wilhelm
1997-08-19  8:08 ` Reload patch to improve 386 code Bernd Schmidt
1997-08-19  8:08 ` Jeffrey A Law
1997-08-19  8:08 ` Bernd Schmidt
1997-08-18 20:47 Mike Meissner
1997-08-18 20:46 Joern Rennecke
1997-08-18 15:36 Toon Moene
1997-08-18 15:11 meissner
1997-08-18 14:53 Monday morning Philippe Laliberte
1997-08-18 14:54 ` Reload patch to improve 386 code Jeffrey A Law
1997-08-18 14:53 meissner
1997-08-18 14:53 Toon Moene
1997-08-18  8:13 Test result for 970814 on native sparc-sun-solaris2.5.1 Klaus Kaempf
1997-08-18  8:22 ` Reload patch to improve 386 code Bernd Schmidt
1997-08-18 10:11 ` Bernd Schmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199708181855.OAA03711@jenolan.rutgers.edu \
    --to=law@hurl.cygnus.com \
    --cc=egcs@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).