Re: Higher level RTL issues

[Jan Hubicka <jh at suse dot cz>]

>   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