[tree-ssa] Loop header copying on trees

[law@redhat.com]

In message <20040216120759.GA6792@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak writ
es:
 >I suspect this is due to the copied headers being often eliminated.
Likewise.  Which leads to a rather interesting question -- can we predict
when we are likely going to be able to eliminate the header (or when we
can not).  If so, then we could use that to tune when we do header
copying.

 > The jump threading on tree-ssa does this kind of loop header copying
 >already, so I assume it might no longer be true (although I haven't
 >tested it).
Yes, we get a certain amount of virtual header copying via jump threading.

It would certainly be interesting to see if loop header copying at the
tree level generally makes things larger or smaller so that we could
make an informed decision :-)

 >yes, this might be a problem. On the other hand, there are a lot of
 >situations where you would like to have as precise control as possible:
 >
 >1) For writing testcases to testsuite, it would be very nice to be be
 >   able to disable all (nonesential) components except for the one you
 >   intend to test.
 >2) When debugging a misscompilation, it would often be useful to control
 >   the optimization options at least on per-function level (and
 >   preferably finer).
I'm certainly not going to argue that those are not useful -- in fact, they are
one of the biggest reasons to keep some of the options.  Though I'd really
prefer to have true unit testing to deal with #1, but that's still a ways
off.

 >Perhaps we can have both, now that we have the generic way of
 >pass management -- we could have easy to use flags only for controlling
 >important features (for users),
Which is what -ON is for :-)

 > and a generic way providing the means to control precisely what is done
 > (for developers).
Well, as a developer, if I want to control things very precisely, I'll
twiddle whatever I need, flags, source code, whatever.

jeff