https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644
--- Comment #7 from Jeffrey A. Law <law at redhat dot com> --- 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 = <something> 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 <&stack_buf(5), buffer_38(D)(34)> # buf_20 = PHI <buffer_17(6), buf_90(32)> # buf_29 = PHI <buf_20(37)> buf_79 = ASSERT_EXPR <buf_29, buf_29 != &stack_buf>; We can see that buf_79 has 3 possible values: &stack_buf, buffer_38 and buf_90 (buf_90 is loop carried) The ASSERT only excludes &stack_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 &stack_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.
