https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110919
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot
gnu.org
Status|ASSIGNED |NEW
--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So what r14-1691-gbc5a2c2e793 does is correct.
# RANGE [irange] unsigned int [0, 0][4, 4][+INF, +INF]
unsigned intD.14 l_14(D) = lD.2821;
vs before:
# RANGE [irange] unsigned int [0, 0][4, +INF]
unsigned intD.14 l_14(D) = lD.2821;
This change causes:
c_16 = (short int) l_14(D);
if (c_16 == 0)
goto <bb 9>; [50.00%]
else
goto <bb 7>; [50.00%]
To be optimized to `goto <bb 7>` because it is on the path where `l_14(D) !=
0`.
And then from:
<bb 7> [local count: 628138967]:
# iftmp.1_7 = PHI <1(3), 0(6)>
We get:
<bb 6> [local count: 628138968]:
# iftmp.1_7 = PHI <_16(3), 0(5)>
Which DOM is not able to jump thread ...
If could copy `bb 6`, then it might be optimizable.
the path along 5, gets optimized to false.
The other path we have:
```
_16 = l_14(D) == 0; (iftmp.1_7)
_4 = (int) iftmp.1_7;
_6 = e;
_19 = _4 == _6;
_5 = ~iftmp.1_7;
_20 = _6 != 0;
_9 = _5 & _20;
_3 = _9 & _19;
...
```
or
```
_20 = _6 != 0;
_19 = _6 == (l_14(D) == 0 ? 1 : 0)
_5 = l_14(D) != 0
_3 = _5 & _20 & _19;
```
`_5 & _19` simplifies down to `l_14(D) != 0` & _6 == 0`
and that with `_6 != 0` gets you false. too.
So I am thinking there is a missing jump thread here.
