https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644
--- Comment #7 from Jeffrey A. Law ---
So optimizing things in remove_range_assertions works for the reduced testcase,
but not for the original testcase. There's a couple of deeper issues that have
to be figured out for the original testcase.
The trick we were trying to utilize is if we could safely copy-propagate a
value which we knew not to be a stack address for an object which might have
been a stack address, then we avoid the false positive. This has a nice
property that it likely improves optimization.
But it's insufficient for the full testcase. First, loops get in the way.
We might have something like this at the top of a loop:
x = phi (a, b)
b =
If we have an subsequent assert that x != b, we can't then replace uses of x
with a. Why? Because the assert refers to the value of b on the current
iteration while the PHI refers to the value of b on the previous iteration.
This issue doesn't show up in the reduced testcase, but does in the full
testcase.
Second, we have to deal with the cascading nature of the asserts. If we go
back to the original testcase the PHI in question looks like this just before
removal of the ASSERT_EXPRs in VRP1:
# _25 = PHI <0B(10), buf_79(16), 0B(26), 0B(30), b_94(15), b_92(19), 0B(9),
buf_80(17), buf_80(39)>
Just looking at chain for buf_79 we have:
# buffer_17 = PHI <_buf(5), buffer_38(D)(34)>
# buf_20 = PHI
# buf_29 = PHI
buf_79 = ASSERT_EXPR ;
We can see that buf_79 has 3 possible values:
_buf, buffer_38 and buf_90 (buf_90 is loop carried)
The ASSERT only excludes _buf so we can't copy propagate buffer_38 or
buf_90 for the uses of buf_79. And we (of course) lose the knowledge that
buf_79 can't be _buf when we drop the ASSERT_EXPRs.
We may still want to use the trick Marc noted in c#2. It applies something
like 20k times during a bootstrap and fixes Wreturn-local-addr-9 in the
testsuite. But it doesn't seem appropriate for stage4.
I find myself wondering if we could tackle this on the alias analysis side by
looking at the PTA solution and see if any of the objects point into the stack.
I also wonder if PTA would benefit from the VRP analysis which excluded the
stack object for certain addresses. All blue sky stuff though.
