From: <tm_gccmail@kloo.net>
To: Steven Bosscher <stevenb@suse.de>
Cc: Ulrich Weigand <weigand@i1.informatik.uni-erlangen.de>, gcc@gcc.gnu.org
Subject: Re: Question about constraints and reload
Date: Mon, 27 Sep 2004 15:12:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.21.0409270434350.27895-100000@mail.kloo.net> (raw)
In-Reply-To: <200409251808.46444.stevenb@suse.de>
On Sat, 25 Sep 2004, Steven Bosscher wrote:
> On Saturday 25 September 2004 16:56, Ulrich Weigand wrote:
> > Steven Bosscher wrote:
> > >What is this necessary for, is there any reason to rely on reload to
> > >turn a constant into a MEM?
> >
> > Certainly! Reload will, as one of its options, force a constant to
> > the literal pool, thereby turning the operand into a MEM. The s390
> > port relies extensively on that feature, because we can only use a
> > limited set of immediate operands, and these differ widely between
> > different instructions. Thus the best way to handle constants is
> > to allow them more or less freely before reload, and have reload
> > choose to use either an actual immediate operand where available,
> > reload the constant into a register, or else push it into the
> > literal pool.
>
> Maybe it's the *easiest* way for your port and other ports to handle
> constants this way, but it may not be the "best way" ;-) I suppose
> you would want to keep constants around mostly for optimization, but
> do we still need that, if the tree optimizers do most of the work?
>
> (bits removed for brevity)
>
> Perhaps we can experiment with putting non-legitimate constants into the
> constant pool and turn them into MEMs somewhere *before* greg and reload.
> Perhaps even already somewhere late in the tree optimizers (turn them
> into CONST_DECLs), or otherwise in some pre-regalloc pass.
This fits nicely into the midRTL/targetRTL paradigm.
The register allocator will still need to generate literal pool entries
for accessing deep stacks on machines with limited displacements on
indirect addressing modes, however.
> Gr.
> Steven
Toshi
next prev parent reply other threads:[~2004-09-27 12:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-25 16:39 Ulrich Weigand
2004-09-25 17:50 ` Steven Bosscher
2004-09-25 18:52 ` Ulrich Weigand
2004-09-25 18:55 ` Steven Bosscher
2004-09-25 21:05 ` Ulrich Weigand
2004-09-27 15:12 ` tm_gccmail [this message]
2004-09-27 18:19 ` tm_gccmail
2004-09-28 11:07 ` Peter Barada
2004-09-28 11:40 ` Ulrich Weigand
-- strict thread matches above, loose matches on Subject: below --
2004-09-25 22:21 Richard Kenner
2004-09-25 15:51 Steven Bosscher
2004-09-27 3:15 ` Geoffrey Keating
2004-09-27 5:05 ` Andrew Pinski
2004-09-27 11:56 ` Geoff Keating
2004-09-27 12:04 ` Geoff Keating
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=Pine.LNX.4.21.0409270434350.27895-100000@mail.kloo.net \
--to=tm_gccmail@kloo.net \
--cc=gcc@gcc.gnu.org \
--cc=stevenb@suse.de \
--cc=weigand@i1.informatik.uni-erlangen.de \
/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).