Hi,
On Wed, 20 Feb 2019, Jeff Law wrote:
> No, I'm saying the distinction between maybe and always uninitialized is
> a false distinction. Code duplication can easily take something that
> triggers a "maybe" warning and turn it into a "always" warning. The
> distinction between them is just bogus.
>
> To take your example
>
> if (a)
> b = 42
> ...
> if (a)
> f(b);
>
> Can be rewritten as
>
> if (a) {
> b = 42
> [ copy of ...]
> f (b);
> } else {
> ...
> f (b); // xxx
> }
No, it cannot. It would introduce a call to f(b) in a path (at xxx) where
it wasn't before. Any transformation that transforms maybe-uninit into
must-uninit is either wrong or introduces more-obviously-dead-than-before
code, like in this variant of yours that is correct:
if (a) {
b = 42
[ copy of ...]
f (b);
} else {
...
if (a) // clearly false, as dominated by if (!a)
f (b); // hence more obviously dead than in original code
}
> x4 = PHI (x0(D), x1, x2, x3)
> use x4;
>
> That's a maybe uninitialized warning by way of the value flow of x0
> through the PHI into x4.
So clearly the use of x4 when reached via edge using x0(D) must be dead
(or we have a real uninit use) but we can't differ because there's only
one use of x4 statically ... nevertheless it's unobviously-dead.
> Which we then simplify into
>
> BB:
> use x0(D)
> goto join
>
> BB:
> x4 = PHI (x1, x2, x3)
> use x4
> goto join
And this makes the uninit use of x0(D) more obviously dead because now the
problematic and non-problematic uses are separated. So, the
transformation introduced more-obviously-dead code, which it just as well
could have removed/not generated, getting rid of the must-uninit
warning.
I guess what I'm saying is that whenever a transformation is about to
introduce a must-uninit from a maybe-uninit that instead all paths leading
to that must-uninit should be removed instead.
> That changes the warning from a maybe-uninitialized into an always
> uninitialized. Note that we still may or may not reach the use at
> runtime. THe distinction between maybe and always is just bogus.
I think as stated that's a bit extreme :) On user code before
optimization the distinction is useful. The problem stems from
us generating warnings somewhen in the middle of the optimization
pipeline. As long as we continue doing that we will always have these
different opinions about what is or isn't rightfully a maybe-uninit or not
:-/
Ciao,
Michael.
