public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Nikolaos Kavvadias <nkavv@physics.auth.gr>
To: gcc-help@gcc.gnu.org
Subject: Extracting information from GCC register allocation
Date: Tue, 14 Nov 2006 15:14:00 -0000	[thread overview]
Message-ID: <4559DD3C.9010704@physics.auth.gr> (raw)
In-Reply-To: <1163450950.10266.ezmlm@gcc.gnu.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Hi there

i have a few questions about register allocation in GCC (mainly for
RISC targets).

First of all, it is true that GCC takes a rather complex way around
things. It seems to me that there are at least four passes for
register allocation:
lreg, greg, and a couple of reload passes (postreload?, rnreg? i'm not
sure). This is understandable due to the incremental way that things have
progressed. Now, to be more specific:

1. Is it possible to emit something close to assembly with
pseudo-registers instead of registers? I mean, is it possible to do this
just before each one of these passes? Or would it be possible to
devise such pass (e.g. an emitter just prior greg). I can see some RTL
stuff with pseudos (e.g. *.lreg) but is it semantically complete in
order to be possible to translate it to assembly (even though with
infinite registers)?

2. Is it possible to explicitly mark the fill/spill instructions (or
RTL statements) in such RTL dumps?

3. Supposedly a <machine.h> description is devised that has a
ridiculously large of registers (so that spills *almost* never will
occur).
Will this approach the effect of register allocation for infinite
registers or there exist other GCC-specific constraints. What are the
limits in the number of registers, registers in classes, allocable
registers etc (i've seen some very bad restrictions in LCC due to the
use of masks with host-dependent size).

And a last one:

4. There is some discussion around gmp/mpfr support in GCC lately. Are
we close to using arbitrary-size integers throught the GCC
infrastructure?

Kind regards
Nikolaos Kavvadias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
 
iD8DBQFFWd08MPiy0tCWlz4RAjgcAKDGY7NojujIPXv0zaNDetHXiyUEWgCgsN1Y
U4wrq1DfbmmOi93KyrGnVeg=
=/zSX
-----END PGP SIGNATURE-----

       reply	other threads:[~2006-11-14 15:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1163450950.10266.ezmlm@gcc.gnu.org>
2006-11-14 15:14 ` Nikolaos Kavvadias [this message]
2006-11-14 18:23   ` Ian Lance Taylor

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=4559DD3C.9010704@physics.auth.gr \
    --to=nkavv@physics.auth.gr \
    --cc=gcc-help@gcc.gnu.org \
    /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).