[Bug tree-optimization/82090] Bogus warning: ‘magic_p’ may be used uninitialized in this function [-Wmaybe-uninitialized]

["aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.