public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: dewar@gnat.com (Robert Dewar)
To: dewar@gnat.com, lord@emf.net
Cc: denisc@overta.ru, gcc@gcc.gnu.org, ja_walker@earthlink.net
Subject: Re: An unusual Performance approach using Synthetic registers
Date: Sun, 05 Jan 2003 14:05:00 -0000	[thread overview]
Message-ID: <20030105134518.DD9FEF2D5D@nile.gnat.com> (raw)

> 1) I don't fully understand why synthregs aren't a common area rather
>    than part of stack frames.  A common area _adds_ code to
>    save/restore synthregs -- but it also increases the number and
>    frequency of references to synthregs.  I don't think L1 is the only
>    cache that can be used better by synthregs.

But if you put the SR's in a global area, then indeed they WILL require
6 byte instructions for their access, and that can greatly increase
pressure on the instruction cache, and will likely slow things down
greatly. 

Once again, you really can not discuss this in the abstract without looking
at the actual code sequences.

If you decide to allocate a base register, as was proposed at one point,
for the synth registers, then you are losing one of your real registers,
and that is a huge hit, you won't begin to buy that back.

With a change in the ABI, and OS, you could use FS or GS as the base
register, but that still does not help much, since the code wold
still be worse than normal access to local variables.

Remember again that the code to access SR's can be no better than the
code we generate right now for all accesses to local variables, function
arguments in memory, and spilled registers.

             reply	other threads:[~2003-01-05 13:45 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-05 14:05 Robert Dewar [this message]
2003-01-06 19:42 ` Tom Lord
2003-01-06  6:49   ` Andy Walker
  -- strict thread matches above, loose matches on Subject: below --
2003-01-08 12:27 Robert Dewar
2003-01-08 12:13 Robert Dewar
2003-01-08 12:21 ` Lars Segerlund
2003-01-08  5:36 Robert Dewar
2003-01-07 21:01 Marcel Cox
2003-01-07 22:53 ` tm_gccmail
2003-01-08  1:05   ` tm_gccmail
2003-01-08  1:22   ` tm_gccmail
2003-01-08 11:45   ` Marcel Cox
2003-01-08 17:29   ` Marcel Cox
2003-01-07 17:19 Robert Dewar
2003-01-07 15:17 Robert Dewar
2003-01-07 17:02 ` Michael S. Zick
2003-01-08  6:56   ` Andy Walker
2003-01-08 12:14     ` Michael S. Zick
2003-01-07 12:32 Robert Dewar
2003-01-07 19:03 ` tm_gccmail
2003-01-07 19:20   ` tm_gccmail
2003-01-08  7:52     ` Andy Walker
2003-01-08 19:29       ` Michael S. Zick
2003-01-08 20:10         ` Michael S. Zick
2003-01-08 20:44         ` tm_gccmail
2003-01-08 21:34           ` Michael S. Zick
2003-01-08 22:05             ` tm_gccmail
2003-01-08  6:08 ` Andy Walker
2003-01-07 12:08 Robert Dewar
2003-01-07 12:10 ` Momchil Velikov
2003-01-06 20:59 Robert Dewar
2003-01-07  5:29 ` Andy Walker
2003-01-07 21:49   ` Marcel Cox
2003-01-07 21:55     ` Branko Čibej
2003-01-07 21:55       ` Marcel Cox
2003-01-08 17:32 ` Tom Lord
2003-01-05 15:47 Robert Dewar
2003-01-05 22:14 ` Tom Lord
2003-01-05 14:08 Robert Dewar
2003-01-05 16:50 ` Michael S. Zick
2003-01-06 19:42 ` Tom Lord
2003-01-06  8:06   ` Andy Walker
2003-01-06 22:45     ` Michael S. Zick
2003-01-07  6:04       ` Andy Walker
2003-01-05 13:13 Robert Dewar
2003-01-06  4:40 ` Andy Walker
2003-01-06 16:46   ` Michael S. Zick
2003-01-07  5:20     ` Andy Walker
2003-01-06 19:42 ` Tom Lord
2003-01-06  6:39   ` Andy Walker
2003-01-06  6:50     ` Daniel Berlin
2003-01-06  9:00       ` Andy Walker
2003-01-05 11:41 Robert Dewar
2003-01-05 16:30 ` Michael S. Zick
2003-01-06  4:53 ` Andy Walker
2003-01-06 19:50 ` Tom Lord
2003-01-06  6:29   ` Andy Walker
2003-01-06 21:53   ` Michael S. Zick
2003-01-07  6:02     ` Andy Walker
2003-01-07 17:41       ` Janis Johnson
2003-01-04 18:12 Robert Dewar
2003-01-04 14:50 Robert Dewar
2003-01-04 18:00 ` Denis Chertykov
2003-01-05  5:53   ` Andy Walker
2003-01-05  5:43 ` Andy Walker
2002-12-27  5:47 Chris Lattner
2002-12-29  0:35 ` Andy Walker
2002-12-29  5:58   ` Chris Lattner
2002-12-29  6:26     ` Alexandre Oliva
2002-12-29 12:04     ` Andy Walker
2002-12-29 13:58       ` Daniel Berlin
2002-12-29 22:41         ` Andy Walker
2002-12-29 15:50       ` Diego Novillo
2002-12-29 22:44         ` Andy Walker
2002-12-30  1:30           ` Zack Weinberg
2002-12-30  2:57             ` Andy Walker
2002-12-30  7:52             ` Michael S. Zick
2002-12-29  7:44   ` Daniel Egger
2002-12-29 12:10     ` Andy Walker
2002-12-30 20:58       ` James Mansion
2002-12-31  3:56         ` Michael S. Zick
2002-12-30  1:09     ` Michael S. Zick
2002-12-30  7:27       ` Daniel Egger
2002-12-30 10:25         ` Michael S. Zick
2002-12-30 20:50         ` Daniel Berlin

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=20030105134518.DD9FEF2D5D@nile.gnat.com \
    --to=dewar@gnat.com \
    --cc=denisc@overta.ru \
    --cc=gcc@gcc.gnu.org \
    --cc=ja_walker@earthlink.net \
    --cc=lord@emf.net \
    /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).