Re: Loop optimizer issues

[law at redhat dot com]

In message <1057257800.5788.5.camel@steven.lr-s.tudelft.nl>, Steven Bosscher wr
ites:
 >Op do 03-07-2003, om 20:12 schreef Zdenek Dvorak:
 >> > Btw. I would agree that most of those constructs resulting in libcalls
 >> > should already have been optimized by tree-ssa, but OTOH I have
 >> > difficulties understanding why removing supporting libcalls would be so
 >> > much easier to implement.  libcalls for REG_NO_CONFLICT blocks are simply
 >> > funny multi-pattern statements, and libcalls with just calls, are well,
 >> > simply calls.  Why is it so much easier to not handle them?
 >> 
 >> It is not somehow terribly difficult (a hundred or two of lines of code,
 >> I guess); but IMO it would be nice to get rid of this feature with
 >> tree-ssa completely.
 >
 >But (and here we go again...) not all front ends use tree-ssa, so while
 >tree-ssa gets rid of it for the front ends that use it, the others
 >(read: g77, Ada (Kenner! ;-)) are stuck with a crippled optimizer.  That
 >may or may not be a reason to keep this particular code around, I don't
 >care.  But let's not just pronounce parts or RTL passes just redundant
 >until all front ends use tree-ssa.
In my ideal world all front-ends will use tree-ssa.  g77 will die and
be replaced by g95 and Ada will have to be converted.

Once we reach this point we can greatly simplify expr.c, calls.c and
likely lots of other code that deals with expanding/optimizing
arbitrarily complex tree nodes, deals with saving stack slots under
construction in the presence of nested callsnested calls, deals
with retroactively dumping variables into the stack after initially
assigning them to registers, path following in cse should disappear,
libcalls, etc.

tree-ssa isn't meant to just be a new optimizer framework -- it's also
meant to simplify the compiler as a whole.

Jeff