This is the mail archive of the
mailing list for the GCC project.
Re: Higher level RTL issues
- To: Jan Hubicka <jh at suse dot cz>
- Subject: Re: Higher level RTL issues
- From: law at redhat dot com
- Date: Tue, 23 Oct 2001 16:31:08 -0600
- cc: Joern Rennecke <amylaar at onetel dot net dot uk>, gcc at gcc dot gnu dot org
- Reply-To: law at redhat dot com
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.
> 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.