http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393
--- Comment #22 from Easwaran Raman <eraman at google dot com> --- (In reply to Marek Polacek from comment #20) > Yes, the patch maybe fixes the debuginfo issue, but there's something else > that is wrong. E.g., on the testcase from PR58018, we have in > reassociate_bb *after* > (and that is important) optimize_range_tests this: > > <bb 7>: > [...] > e.1_16 = _14 & e.0_15; > _17 = f_12 >= 0; > _18 = (int) _17; > e.1_19 = e.1_16 & _18; > _20 = f_12 > 0; > _23 = f_12 > 0; > _24 = (int) _23; > _21 = (int) _20; > e.1_22 = e.1_19 & _21; > [...] > > Now, in reassociate_bb, we go over the stmts, from the last stmt to the > first stmt in the bb. For the appropriate stmts, we call rewrite_expr_tree > to rewrite the linearized statements according to the operand_entry_t ops > vector, in this case we call it on > e.1_22 = e.1_19 & _21; > and the vector ops contains > Op 0 -> rank: 589826, tree: _14 > Op 1 -> rank: 3, tree: _24 > Op 2 -> rank: 1, tree: e.0_15 > > In rewrite_expr_tree, we recursively call this function on e.1_19, whose > SSA_NAME_DEF_STMT is > e.1_19 = e.1_16 & _18; > This stmt is then transformed into > e.1_19 = _24 & e.0_15; > > But, at the point where e.1_19 is defined, the _24 isn't defined yet! > > So, it seems, ensure_ops_are_available should handle a situation like this. > However, it doesn't: perhaps the issue is that find_insert_point won't find > the right insert point (the stmt is e.1_19 = e.1_16 & _18;, the dep_stmt is > _24 = (int) _23;), in there we have: > > if (gimple_uid (insert_stmt) == gimple_uid (dep_stmt) > && gimple_bb (insert_stmt) == gimple_bb (dep_stmt) > && insert_stmt != dep_stmt) > insert_stmt = appears_later_in_bb (insert_stmt, dep_stmt); > else if (not_dominated_by (insert_stmt, dep_stmt)) > insert_stmt = dep_stmt; > return insert_stmt; > > Neither of these condition holds; gimple_uid of the dep_stmt is 0 and of > insert_stmt it is 16. Thus, find_insert_point returns e.1_19 = e.1_16 & > _18;. That's wrong, I suppose. > Maybe the issue is that if the two stms are in the same bb, we just look at > their UIDs and based on that we find out the dependency, but the new stms > coming from optimize_range_tests don't have gimple UIDs set, thus this > can't work. > Likely I'm wrong, would appreciate if someone could shed some light on this. > > Looking into it more... The problem with this test case is that there is a statement with uid 0 that is being compared. The assumption was every stmt will have a UID in a monotonically non-decreasing order. This is broken here because force_gimple_operand_gsi generates new stmts that don't have a UID. The proposed patch generates UIDs for these newly generated statements but I think this is a bit ugly and fragile now.
