https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|10.0 |11.0
--- Comment #4 from Jeffrey A. Law <law at redhat dot com> ---
Yes, the loop PHI is where things start, but the PHI in the latch block is just
as problematical it not more. It's the use in the latch PHI that uninit.c
considers unguarded.
We could duplicate the latch block (thus creating two backedges to the top of
the loop). Of course this mucks up the loop structures to some degree, so
it's not a great solution.
We could unroll the loop which ought to untangle things enough, but that's a
codesize regression and just twiddling the loop bounds would be enough to bring
the warning back, so I consider this a non-starter.
Peeling the first iteration has the same effect as unrolling on this specific
test and I think would resolve it. Peeling the first iteration would also work
if the loop bounds were different.
Jump threading often has the same effect as peeling off an iteration. DOM3
discovers the opportunity, but doesn't actually thread the jump presumably
because doing so will muck up the loop structure.
I looked at Bin's recent work hoping it might be enough to help uninit.c
realize the use is guarded, but it isn't. It may be extendable to handle this
case though. Unsure.
Given we don't really have a viable path forward yet, I'm going to punt this to
11.
