So as noted in the PR, we're failing to discover an important jump
thread during threading from VRP. This is a case where the symbolic
range is actually more useful than constants in the range.
There's some talk of improving this in VRP for gcc-8, but in the mean
time, fixing this by improving threading is feasible and actually takes
a useful step in the long term plan.
The central idea here is to allow the VRP instance of jump threading to
record conditions from ASSERT_EXPRs into the available expression table.
We can see the symbolic ranges from those expressions. Of course,
there's some bits to put in place first.
Patch #1 is pure refactoring/movement. A couple routines are turned
into member functions of the scoped hash tables and another is kept as
normal function but moved into a more natural location which also makes
it available in DOM and VRP.
Patch #2 improves DOM's ability to discover implied equivalences when an
object is known to have the value 0. This avoids a regression due to
changes in patch #3. There's more that could be done here. But I've
tried to keep the scope of what's changing small due to being in stage4.
Patch #3 pushes ASSERT_EXPR handling out of the core of the threader and
into callbacks used by VRP. It should have been done this way to begin
with. It's so painfully obvious 10+ years later.
Patch #4 turns random order walk for threading from VRP into a domwalk
and refactors some common code from VRP/DOM into the threader itself.
Patch #5 allows recording equivalences from ASSERT_EXPRs and looking up
objects in the expression hash table in the VRP threading callback. At
which point we're done. Not surprisingly, with the infrastructure in
place patch #5 is actually trivial.
The set looks much bigger than it really is. That's largely because of
refactoring that's going on.
Commit plan:
I'm committing patches #1 and #2 together and giving them ~12hrs to
simmer. The improvements in DOM could possibly trigger the need to
adjust expected outputs of tests. I haven't seen in the need on x86.
I'm going to be doing some ppc64le testing tomorrow. It's been
surprisingly hard to get a machine from our testpool.
Assuming no issues with #1/#2, then I'll proceed to #3/#4. I don't have
any real concerns with #3/#4, but I want to isolate them from #5 just in
case #5 needs further testsuite tweakage. Assuming all goes well, #5
would be committed Friday.
Jeff
