From: Jan Hubicka <jh@suse.cz>
To: law@redhat.com
Cc: Jan Hubicka <jh@suse.cz>, Joern Rennecke <amylaar@onetel.net.uk>,
gcc@gcc.gnu.org
Subject: Re: Higher level RTL issues
Date: Wed, 24 Oct 2001 07:59:00 -0000 [thread overview]
Message-ID: <20011024165850.M11456@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <32418.1003876268@localhost.localdomain>
> In message < 20011023120240.G12992@atrey.karlin.mff.cuni.cz >you write:
> > > How about commoning of libcall addresses and other special constants?
> > > Are you going to rely on post-lowering phases to do that, or do you
> > > plan to display this stuff in the CALL_FUSAGE or some now field of
> > > CALL_INSNs?
> > I believe we still must do (g)cse after lowering, as at almost each riscy
> > architecture this is going to introduce dozen of new constants and
> > temporaries that can be cseed, but we probably don't need the "full
> > strength cse+gcse" we've somehow failed to reach, as for instance
> > load/store motion and friends> can be done only on midlevel.
> It is likely that we will continue to have a [g]cse pass of some kind that
> runs after lowering from generic to target specific RTL. It is *hoped* that
> it can be a simpler, more compile time efficient pass than we currently have
> with cse or gcse.
>
> What makes you think we can only do lsm on target rtl? There's no reason
> they can not be done on the generic RTL.
Thats what I wanted to say - that we can drop some of complexity of current
gcse on lowlevel tree, as lsm is, since it don't make sense to rerun it after
midlevel->lowlevel generation.
>
> > Another pass that may make sense at lowlevel is strength reduction, but
> > maybe we can do it at midlevel just by knowing the addressing modes of
> > target machine.
> I don't really want to get into the loop optimizer right now or better stated
> I think solving our loop optimizer problems needs to be handled independently
> of adding a generic RTL IR to GCC and I personally prefer to focus on the
> generic RTL issues right now.
Sure. I am trying to get some of bits for writing new loop optimizer ready
in meantime, so I am focusion on the oposite side of this problem.
Honza
>
> jeff
next prev parent reply other threads:[~2001-10-24 7:59 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-09 19:46 law
2001-10-09 20:54 ` Diego Novillo
2001-10-09 21:27 ` Daniel Berlin
2001-10-09 21:49 ` Diego Novillo
2001-10-09 22:23 ` Daniel Berlin
2001-10-19 14:39 ` law
2001-10-19 12:19 ` law
2001-10-09 21:18 ` Daniel Berlin
2001-10-09 21:33 ` Diego Novillo
2001-10-19 14:37 ` law
2001-10-19 15:53 ` Daniel Berlin
2001-10-22 9:31 ` law
2001-10-22 11:49 ` Daniel Berlin
2001-10-13 2:27 ` Jan Hubicka
2001-10-19 12:03 ` law
2001-10-21 10:40 ` Jan Hubicka
2001-10-22 8:28 ` law
2001-10-22 8:36 ` Daniel Berlin
2001-10-22 8:56 ` law
2001-10-22 9:07 ` Jan Hubicka
2001-10-22 11:32 ` law
2001-10-22 15:07 ` Richard Henderson
2001-10-23 15:16 ` Joern Rennecke
2001-10-22 16:22 ` Joern Rennecke
2001-10-23 3:02 ` Jan Hubicka
2001-10-23 15:28 ` law
2001-10-24 7:59 ` Jan Hubicka [this message]
2001-10-22 11:30 law
2001-10-22 13:10 ` Daniel Berlin
2001-10-22 14:02 ` law
2001-10-22 14:25 ` Daniel Berlin
2001-10-22 14:28 ` Daniel Berlin
2001-10-22 14:48 ` law
2001-11-13 13:41 ` Diego Novillo
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=20011024165850.M11456@atrey.karlin.mff.cuni.cz \
--to=jh@suse.cz \
--cc=amylaar@onetel.net.uk \
--cc=gcc@gcc.gnu.org \
--cc=law@redhat.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).