This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-profiling] Fix return predictors
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: jh at suse dot cz
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 13 Aug 04 21:21:23 EDT
- Subject: Re: [tree-profiling] Fix return predictors
[Moved from gcc-patches to gcc.]
> IMHO it is an absolute _must_ that the old loop optimizer can
> be removed before GCC 3.5 is released.
Yep, that would be nice tought ;)
I very strongly disagree. We have no hope of catching all loop invariants at
tree level without putting a tremendous amount of knowlege into the tree
formats and, even if we did it, that knowlege would interfere with other
optimizations.
For example, if you have
j = j op C;
in a loop, what values of C can be put into the operation instruction is a
very strong function both of the machine and the operation. Getting it wrong
by assuming *every* C is a loop invariant that should be moved out of the
loop causes very high register pressure. Moreover, it makes it harder to see
what's going on in the tree.
It is the role of the RTL optimizers to handle these sorts of machine
dependencies because they have all the necessary information readily at hand.