[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[prathamesh3492 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78319

--- Comment #8 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Richard Biener from comment #7)
> (In reply to prathamesh3492 from comment #6)
> > (In reply to Richard Biener from comment #5)
> > > It's a matter of costs (here BRANCH_COST and its uses in fold and ifcombine).
> > > 
> > > You don't mention what IL differences your patch causes (I'll check soon
> > > myself).
> > The difference caused by r249195 is the following in forwprop dump on
> > cortex-m7:
> > 
> > before:
> > <bb 2>:
> >   _1 = n_20(D) != 0;
> >   _2 = m_21(D) != 0;
> >   _3 = _1 | _2;
> >   if (_3 != 0)
> >     goto <bb 4>;
> >   else
> >     goto <bb 3>;
> > 
> > after:
> > <bb 2>:
> >   _1 = n_20(D) != 0;
> >   _2 = m_21(D) != 0;
> >   _25 = n_20(D) | m_21(D);
> >   if (_25 != 0)
> >     goto <bb 4>;
> >   else
> >     goto <bb 3>;
> > 
> > _3 = _1 | _2 is replaced by _25 = n_20(D) | m_21(D)
> 
> But there are still uses of _1 (or _2) left, right?
> 
> So it might be that tree-ssa-uninit.c simply needs to be taught
> that X | Y != 0 means X != 0 || Y != 0.  I think this is done
> in normalize_preds though it looks like it is already handled
> to some extent.  But I see
> 
> [BEFORE NORMALIZATION --[USE]:
> blah (v_30);
> is guarded by :
> 
>  (.NOT.) _1 != 0 (.AND.) _5 != 0
> 
> 
> [AFTER NORMALIZATION -- [USE]:
> blah (v_30);
> is guarded by :
> 
> _5 != 0 (.AND.)  (.NOT.) _1 != 0
> 
> while
> 
> [BEFORE NORMALIZATION --[DEF]:
> v_30 = PHI <r_12(D)(5), v_29(6)>
> is guarded by :
> 
> m_11(D) != 0
> (.OR.)
> _1 != 0
> (.OR.)
> _2 != 0
> 
> 
> [AFTER NORMALIZATION -- [DEF]:
> v_30 = PHI <r_12(D)(5), v_29(6)>
> is guarded by :
> 
> m_11(D) != 0
> (.OR.)
> m_11(D) != 0
> (.OR.)
> n_10(D) != 0
> (.OR.)
> l_13(D) != 0
> (.OR.)
> r_12(D) != 0
> 
> so somehow it expands it in one case but not in the other.
> 
> Can you investigate?
I will give a try.
> 
> > forwprop dump before:
> > http://pastebin.com/vdTs1B0V
> > 
> > forwprop dump after:
> > http://pastebin.com/XuYVGG0z
> > > For the issue at hand I suggest to XFAIL for affected architectures.
> > Ok thanks, I will xfail this test on arm-none-eabi.
> > Ideally I would like to xfail only for cortex-m7 (and not other sub-targets).
> > Is it possible to check which sub-target is in effect with dejagnu ?
> 
> I don't think so.
Ok thanks, in that case I will XFAIL it on arm-none-eabi.

Thanks,
Prathamesh
> 
> > Thanks,
> > Prathamesh
> > > 
> > > Generally the late uninit pass needs a rewrite to be conservative (make its
> > > data-flow compute must-be-may-uninitialized rather than erring on the false
> > > positive side when its analysis gives up).
> > > 
> > > A good research project would be to write an IPA static analysis pass that
> > > performs at least some trivial "optimization" itself (constant folding
> > > and propagation) but does not do any IL changes.