[Bug tree-optimization/89182] [8/9 Regression] [graphite] ICE in extract_affine, at graphite-sese-to-poly.c:280

[rguenth at gcc dot gnu.org]

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).