https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78319
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2016-11-16
Ever confirmed|0 |1
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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?
> 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.
> 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.
