This is the mail archive of the
mailing list for the GCC project.
Re: Higher level RTL issues
> 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
> > 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.