On 10/23/2021 3:32 PM, Jeff Law wrote:
On 10/21/2021 12:20 PM, Jeff Law wrote:
So if we're referring to those temporary const/copy propagations
"escaping" into Ranger, then I would fully expect that to cause
problems. Essentially they're path sensitive const/copy propagations
and may not be valid on all the paths through the CFG to the statement
where the propagation occurs
Yeah. disabling the global ranger should help, plus making sure you
don't use the ranger in the midst of the path sensitive changes.
I think we should first try to remove those temporary const/copy
propagations. As I noted in a different follow-up, I can't remember
if they were done as part of the original non-copying threader or if
they enabled further optimizations in the copying threader. If its
the former, then they can go away and that would be my preference.
I'll try to poke at that over the weekend.
OK. So those temporary propagations are still useful. Here's a
simple example (pr36550, but there are others):
Actually, isn't pr36550 the one you already noted?
I saw a few other issues when I just removed that chunk of code.
First, we get an *execution* failure in c-torture/builtins/<something>
That one was exceedingly strange. I didn't save it, but it'll almost
definitely raise its ugly head again.
Wnon-null-4.C. We fail to thread a path and as a result trigger a bogus
warning
One of the other W* tests failed with a bogus warning too. But it's
fixed by some pending work from Martin S, so I didn't worry much about it.
So in all, not too bad. I may do some instrumentation for the pr36550
issue -- while it's not showing a lot of fallout in the testsuite, it
would be interesting to see how it affects codegen on gcc itself.
Jeff
