------- Additional Comments From law at redhat dot com 2005-07-28 22:00 -------
The attached patch is a piece of what will be necessary to fully optimize this
testcase in the future.
The first step is getting VRP to discover that all the paths to the bytes == 0
test have a range of either [0, 0] or ~[0, 0]. Two changes are necessary to
make that happen.
a. When we're searching for uses of a conditional's operand, we currently
ignore any uses in blocks that have been visited. That causes us to miss
uses, particularly those in PHI nodes at dominance frontiers. With that
fixed, we get some additional ASSERT_EXPRs on the paths out of the loop
to the bytes == 0 test. The first hunk in the patch takes care of this
issue.
b. When evaluating a PHI, we have some checks to avoid expanding ranges
over and over and over again as we gain more information at PHI nodes.
This is fine and good, except that it's too aggressive. Consider if
we are meeting two ranges [ , -1] and [1, ]. vrp_meet will correctly
give us ~ [0, 0], but the code in vrp_visit_phi_node will try to expand
the [ , -1] range rather than use the anti-range returned by vrp_meet.
This results in getting a VARYING range rather than ~[0, 0]. THe second
hunk in the attached patch fixes that little goof.
Once VRP computes all the necessary information, it's just a matter of using
that information to perform the optimization we want. I haven't decided what
the best approach would be. It's really a jump threading optimization.
a. Jump threading in tree-vrp. This may not be as sick as it sounds. The
idea would be that much of the jump threading code would become a common
routine used by tree-vrp and DOM. That would probably mean the remaining
VRP bits in DOM would disappear since tree-vrp would perform any threading
based on VRP.
b. Make range information persistent so that DOM could use the VRP information
computed by tree-vrp.
Anyway, this is definitely not stuff we want to try to squeeze into 4.1. So I'm
going to attach my work-to-date so that nobody has to recreate it when we open
up stage1 for GCC 4.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21559
