https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89182
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2019-02-04
CC| |matz at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Target Milestone|--- |8.3
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. We're running into a SSA name we failed to register as parameter
to the region (from number_of_latch_executions of a contained loop). The
SCOP detection code does analyze the result via scalar_evolution_in_region
and computes it to zero. But later it doesn't because of
name_registered_for_update_p evaluates to true (the transform of an earlier
SCOP has succeeded).
The course of action is of course to not repeat analyzing scalar evolutions
(or elide its follow_copies_to_constant "hack") but record analysis results
somewhere.
Another issue that would side-step this is scalar_evolution_in_region calling
analyze_scalar_evolution at all because it only skips analyzing plain SSA
expressions for whether they are "defined_in_sese_p" rather than analyzing
2 - md_89 we pass in (md_89 would be !defined_in_sese_p). We end up passing
a "bogus" loop to analyze_scalar_evolution which causes the result to not
be cached (side-stepping the above issue).
