From: Andy Walker <ja_walker@earthlink.net>
To: Tom Lord <lord@emf.net>, dewar@gnat.com
Cc: gcc@gcc.gnu.org
Subject: Re: An unusual Performance approach using Synthetic registers
Date: Mon, 06 Jan 2003 08:06:00 -0000 [thread overview]
Message-ID: <E18VRwv-0002xy-00@scaup.mail.pas.earthlink.net> (raw)
In-Reply-To: <200301051420.GAA27749@emf.net>
On Sunday 05 January 2003 08:20 am, Tom Lord wrote:
> For ja_walker (and, I'd guess this is important): that means that
> just blindly "tricking" the register allocator isn't the best way to
> do it -- because it makes more sense to store _some_ values in
> synthregs than it does to store locals and arguments in them. So, add
> some weights somewhere or else you'll waste synthregs left and right.
> Otherwise, what you lose for locals/args (the dominant case) will
> probably exceed what you gain for other values.
We shall have to see. I fully expect to have to rewrite the whole thing as
soon as we get a few runs to see what it is really doing. This is my third
rewrite already.
The implementation is a little more complicated than "blind trickery". But
not much. My fond hope is that the additional restrictions will be
sufficient, and that the optimizer will quite happily use the Synthetic
registers when it is prudent to do so. If not, I may have to do some tuning
by disparaging other alternatives, either a little, or a lot.
I have created a new register class, "k" for Synthetic. (Obvious, no? Not
to me either!) "k" class registers are not base class registers, index class
registers, or general registers. They are also not general operands.
Therefore, they do not get sucked into being used for everything, and I
minimize the code changes and checking I have to do. Also, the optimizer and
allocator passes get every oportunity to generate the cleanest code with the
real restrictions in mind. Big plus here: we may be able to keep Reload's
sticky fingers off the natural registers if there are enough Synthetic
registers. If there are enough natural registers, then register allocation
is trivial, register coalescing is unnecessary, and spills never happen.
If Synthetic registers are used, then the hard frame pointer is required.
Hard frame pointer is realigned onto a 32 byte boundary, and old frame
pointer and pc are moved accordingly. Synthetic registers are the 32 full
word locations immediately below the hard frame pointer. In light of Robert
Dewar's comments about stack slot accesses through the hard frame pointer, I
am reconsidering this.
I have created some new predicate routines to check whether an operand is,
for example, a general_or_synth_operand. These are used in instruction
predicates for instructions that might use a Synthetic register. Appropriate
predicates prevent Synthetic register to memory instructions, in exactly the
same way that memory-to-memory instructions are prevented.
All Synthetic registers are mode SI. Period. If this does not prove out my
concept in at least a few instances, then the concept will never work, no
matter how many other modes I add. If it does prove out my concept, I can
make a rational decision about how much extra work to put into implementing
other modes.
The list of instructions that might operate on a Synthetic register is short:
mov, add, sub, neg, and, or, xor, ror, rol, ashl, ashr, and lshr (sp?). In
addition, a synthetic register may be a source for a mul or divmod. For this
short list of instructions, a Synthetic register can be a source or
destination, in conjunction with a register, or it may be a destination in
conjunction with an immediate value.
The instructions that might use a Synthetic register are almost unchanged.
"k" registers are added as the first alternative, with the same restrictive
syntax used for "m", memory, references.
For register allocation, the allocation list starts with and runs through all
the Synthetic registers before trying a general register.
Finally, in the routine that generates the register-representative character
string to be concatenated to the current instruction, I intercept Synthetic
registers and generate appropriate base-offset addresses. I know I do not
know exactly what I am doing here, so it will take some sorting out. The
formulation is clear. The RTL is not.
I do not expect this to be enough, but it is start.
Andy
next prev parent reply other threads:[~2003-01-06 7:45 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2003-01-06 22:45 ` Michael S. Zick
2003-01-07 6:04 ` 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:05 Robert Dewar
2003-01-06 19:42 ` Tom Lord
2003-01-06 6:49 ` 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=E18VRwv-0002xy-00@scaup.mail.pas.earthlink.net \
--to=ja_walker@earthlink.net \
--cc=dewar@gnat.com \
--cc=gcc@gcc.gnu.org \
--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).