On Sun, 2020-04-05 at 20:48 +0200, Richard Biener wrote:
> On April 5, 2020 5:25:15 PM GMT+02:00, Jeff Law via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
> > So here's an approach to try and address PR80635.
> >
> > In this BZ we're getting a false positive uninitialized warning using
> > std::optional.
> >
> > As outlined in the BZ this stems from SRA using a VIEW_CONVERT_EXPR
> > which isn't
> > handled terribly well by the various optimizers/analysis passes.
> >
> > We have these key blocks:
> >
> > ;; basic block 5, loop depth 0
> > ;; pred: 3
> > ;; 2
> > # maybe_a$m_6 = PHI <_5(3), maybe_a$m_4(D)(2)>
> > # maybe_a$4_7 = PHI <1(3), 0(2)>
> > <L0>:
> > _8 = maybe_b.live;
> > if (_8 != 0)
> > goto <bb 6>; [0.00%]
> > else
> > goto <bb 7>; [0.00%]
> > ;; succ: 6
> > ;; 7
> >
> > ;; basic block 6, loop depth 0
> > ;; pred: 5
> > B::~B (&maybe_b.D.2512.m_item);
> > ;; succ: 7
> >
> > ;; basic block 7, loop depth 0
> > ;; pred: 5
> > ;; 6
> > maybe_b ={v} {CLOBBER};
> > resx 3
> > ;; succ: 8
> >
> > ;; basic block 8, loop depth 0
> > ;; pred: 7
> > <L1>:
> > _9 = VIEW_CONVERT_EXPR<bool>(maybe_a$4_7);
> > if (_9 != 0)
> > goto <bb 9>; [0.00%]
> > else
> > goto <bb 10>; [0.00%]
> > ;; succ: 9
> > ;; 10
> >
> > Where there is a use of maybe_a$m_6 in block #9.
> >
> > Of course maybe_a$m_6 only takes the value of maybe_a$m_4(D) when we
> > traverse the
> > edge 2->5 but in that case maybe_a$4_7 will always have the value zero
> > and thus
> > we can not reach bb #9.. But the V_C_E gets in the way of the analysis
> > and we
> > issue the false positive warning. Martin Jambor has indicated that he
> > doesn't
> > see a way to avoid the V_C_E from SRA without reintroducing PR52244.
> >
> > This patch optimizes the V_C_E into a NOP_EXPR by verifying that the
> > V_C_E folds
> > to a constant value for the min & max values of the range of the input
> > operand
> > and the result of folding is equal to the original input. We do some
> > additional
> > checking beyond just that original value and converted value are equal
> > according
> > to operand_equal_p.
> >
> > Eventually the NOP_EXPR also gets removed as well and the conditional
> > in bb8
> > tests maybe_a$4_7 against 0 directly.
> >
> > That in turn allows the uninit analysis to determine the use of
> > maybe_a$_m_6 in
> > block #9 is properly guarded and the false positive is avoided.
> >
> > The optimization of a V_C_E into a NOP_EXPR via this patch occurs a
> > couple
> > hundred times during a bootstrap, so this isn't a horribly narrow
> > change just to
> > fix a false positive warning.
> >
> > Bootstrapped and regression tested on x86_64. I've also put it through
> > its paces
> > in the tester. The tester's current failures (aarch64, mips, h8) are
> > unrelated
> > to this patch.
> >
> >
> > Thoughts? OK for the trunk? Alternately I wouldn't lose sleep moving
> > this to
> > gcc-11.
>
> ISTR Ada uses V_C_E to implement checks on value ranges to types. We need to
> make sure to not interfere with this.
Eric indicated they use it a lot less often than they used to, but yes we should
try to make sure we're not interfering.
I'll enable Ada for the native targets in the tester and see if that spits out
anything concerning.
Jeff
