------- Comment #45 from rguenth at gcc dot gnu dot org 2009-12-19 21:10
-------
(In reply to comment #41)
> Indeed. The PRE issue could be fixed by fixing PR38819 not in the way it is
> done now but "properly" detect the invalid situations during ANTIC computation
> and simply never mark trapping expressions so. At the current point its
> hard to tell if the insertion is valid because the original expression is
> always executed if the insertion point is - simply because we no longer
> know where the original expression was.
>
> Thus, the "proper" place (err, I think at least) is during translating
> ANTIC_OUT through the basic-block to ANTIC_IN (thus, in clean()). It
> might be a bit expensive, though pre-computing if a basic-block possibly
> exits the CFG could speed this up significantly. Another "proper" place
> would be to add fake edges to exit for each such point in the CFG
> (basically split blocks at each possibly noreturn call and add an edge
> to exit). But that might be even more expensive.
Doing this in a straight-forward way shows that the division isn't
partially redundant:
<bb 4>:
# j_2 = PHI <1(3), j_101(7)>
jmini_55 = j_2 - i_1;
D.1530_57 = *nnd_28(D);
if (i_1 > D.1530_57)
goto <bb 7>;
else
goto <bb 5>;
<bb 5>:
D.1576_60 = D.1530_57 - i_1;
D.1577_64 = (character(kind=4)) D.1576_60;
D.1583_68 = (character(kind=4)) D.1582_45;
countm1.6_69 = D.1577_64 / D.1583_68;
...
if (countm1.6_69 == 0)
goto <bb 7>;
else
goto <bb 6>;
<bb 6>:
...
if (countm1.6_81 == 0)
goto <bb 7>;
else
goto <bb 6>;
<bb 7>:
...
if (j_2 == D.1560_49)
goto <bb 8>;
else
goto <bb 4>;
<bb 8>:
i_103 = i_1 + 1;
if (i_1 == D.1582_45)
goto <bb 9>;
else
goto <bb 3>;
The division may be not executed if i > nnd is always true which it is
if nnd is <= 2. Thus fixing PRE is not the solution here (LIM will
still move the expensive division if it is proven to not trap by VRP though).
That is, computing coumtm before the loop entry check as suggested by
Michael.
But then going with the VRP solution sounds like a better idea to me
(to fix this particular regression, that is).
PR42438 tracks the PRE issue now which IMHO is unrelated to this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
