Re: Higher level RTL issues

[Jan Hubicka <jh at suse dot cz>]

> > Third, we want to delay exposure and lowering of libcalls.  libcalls sequences
> > are a disgusting hack and cause as many problems as they solve.  The tricky
> > part is that we need to unnest potential libcalls at the tree level so that
> > we avoid all the stack slot saving BS when we lower from a simple "div"
> > instruction to a __divsi3 libcall (as an example).
> 
> 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.

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.

Honza
> 
> --
> Joern Rennecke                  |            gcc expert for hire
> amylaar@onetel.net.uk           |  send enquiries to: jwr_jobs@onetel.net.uk