https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85989
rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #3 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org>
---
Created attachment 44217
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44217&action=edit
candidate patch
(In reply to Richard Biener from comment #2)
> for (b_P5 = 0; b_P5 < 8; b_P5++) {
> P26 = P29;
> P29 = -(int)*P5;
> }
>
> for (b_P5 = 0; b_P5 < 3; b_P5++) {
> for (P29 = 0; P29 < 9; P29++) {
> i0 = P26;
> if (P26 < 0) {
> i0 = 0;
>
> so the sign of P29 does matter since it flows backwards into P26 -- possibly
> exactly the issue that causes the bug. The PHIs look like
>
> <bb 5> [local count: 286363364]:
> _3 = *P5_32(D);
> _4 = (int) _3;
> P29_36 = -_4;
> b_P5_37 = b_P5_20 + 1;
>
> <bb 6> [local count: 322154758]:
> # b_P5_20 = PHI <b_P5_37(5), 0(16)>
> # P26_22 = PHI <P29_23(5), 10(16)>
> # P29_23 = PHI <P29_36(5), 10(16)>
> if (b_P5_20 <= 7)
> goto <bb 5>; [88.89%]
> else
> goto <bb 14>; [11.11%]
>
> and you can see that parallel assignment to P29_23 and to P23_22 from P29_23
> while backprop seems to evaluate PHIs in isolation, eventually losing
> that P26_22 = P29_23 copy?
Yeah.
> This looks hard to fix btw... process_block needs to be refactored
> to process all vars from PHI defs in parallel.
>
> Richard?
Processing them linearly is OK since the first phase sets up an
optimistic result based on a "backward" walk and the second phase
is supposed to find a correct maximal fixed point. The problem
was that we weren't even doing the linear processing properly,
since a reference to a previously-processed PHI was being treated
as a back edge reference to an unprocessed PHI.
The attached fixes the test, but I'll run it through more testing tomorrow.
