https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115494
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
hmm, I think I see what is happening.
So we start with:
# RANGE [irange] unsigned char [0, 1] MASK 0x1 VALUE 0x0
_4 = (unsigned charD.20) iftmp.2_8;
# RANGE [irange] unsigned char [254, +INF] MASK 0x1 VALUE 0xfe
_5 = ~_4;
if (_5 != _14)
goto <bb 6>; [66.00%]
else
goto <bb 5>; [34.00%]
bb5:
# RANGE [irange] unsigned char [0, 1] MASK 0x1 VALUE 0x0
_17 = ~_14;
# RANGE [irange] unsigned char [0, 1] MASK 0x1 VALUE 0x0
_18 = _4 | _17;
...
bb6:
...
_15 = ~_14;
_7 = _4 | _15;
So PRE is consolidating _17 and _15 as being the same and using _17 as the
leader.
And when it realizes _4 is 1 on the bb6 and goes to do the simplify, does 1 |
_17 but gets simplified to 1 but `~_14` range in bb6 is not [0,1].
So the issue is PRE is not removing the range from _17 before doing the
simplification while consolidating the two ssa names.
Richi,
can you look into this further? match is doing exactly what it is being asked
of it but it looks like PRE is messing up due to conditional ranges.
