https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82090
--- Comment #5 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- [from the POC patch] It seems that every missed thread (due to inability of the threader, or due to cost restraints) is a potential false positive for the uninit code. Perhaps what we need is a way to identify threading opportunities without doing the actual threading. The attached is a proof-of-concept that does just that. Basically a lof of these PRs look like: x_5 = PHI <UNDEF(10), x_8(20), x_10(30)> ... ... if (cond_8) use(x_5); This looks like a path from the definition of x_5 to the cond_8 check. If the incoming path through BB10 can be determined to elide the use of x_5, we could disregard this as a false positive. This patch solves PR82090, but it would need to be properly incorporated into the uninit pass. For instance, I'm finding paths from USE back to DEF, but the uninit pass is in a much better position to tell us what the starting point of the path is. It's likely to be further up the chain through a maze of feeding PHIs. This is just meant as a stop gap to help in reducing the false positive rate, nothing fancy. Maybe the work by Martin Liska and Richi on loop unswitching would be a better solution. Anywhoo... Maybe someone with knowledge of the uninit pass could explore this. Just a thought.
