https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118167
--- Comment #6 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Sam James from comment #5)
> I suppose it's a job for prange?
I don't think so. I think it related to integral values being bumped by 1, and
pointer values being bumped by 4.
It seems the ivopts recognizes the bump by one, and turns
<bb 5> [local count: 1014686024]:
# sum_15 = PHI <sum_11(10), 0(9)>
# iter_17 = PHI <iter_12(10), begin_7(9)>
if (end_8 > iter_17)
goto <bb 7>; [99.96%]
else
goto <bb 6>; [0.04%]
into
<bb 5> [local count: 1014686024]:
# sum_15 = PHI <sum_11(10), 0(9)>
# iter_17 = PHI <iter_12(10), begin_7(9)>
if (iter_17 != end_8)
goto <bb 7>; [99.96%]
else
goto <bb 6>; [0.04%]
With pointers,It seems it cannot transform the > into != .. probably out of
conservativeness about the potential +1, +2, and +3 values. (If the starting
values were "end = begin + 3" the transformation to != wouldn't work). With
a bump by 1, it can always be done.
Regardless, this transformation eventually allows threading and DOM to
simplify a PHI to a copy. Once its just a copy, its much easier to apply
relations and realize the assert can never trigger.
blame byte pointers? :-)
I don't see anything obvious the ranger can pickup on here. It seems to fall
into the loop analysis field, and requires a guarantee that 'begin' and 'end'
are exactly a multiple of 4 bytes apart.
at least that is what it looks like to me.
