[Bug tree-optimization/97630] New: [11 Regression] SLP vectorizer leaks memory

[Bug tree-optimization/97630] New: [11 Regression] SLP vectorizer leaks memory

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97630

            Bug ID: 97630
           Summary: [11 Regression] SLP vectorizer leaks memory
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

We currently leak all memory pointed to from SLP cycles (not the SLP nodes
themselves, but the scalar_stmts array and similar).  This is because we
manage memory by reference counting but that breaks down with cycles.

One example is gcc.dg/vect/bb-slp-57.c

[Bug tree-optimization/97630] [11 Regression] SLP vectorizer leaks memory

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97630

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-10-29
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1
   Target Milestone|---                         |11.0
             Status|UNCONFIRMED                 |ASSIGNED

[Bug tree-optimization/97630] [11 Regression] SLP vectorizer leaks memory

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97630

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
The least resistance attempt to fix it would be to keep track of allocated
SLP trees in _slp_tree::operator new/delete using a hash_set<> for example
and call the DTOR on still allocated ones when destroying the alloc-pool.
A double-linked list of all allocated nodes would work as well.

Otherwise each vect_free_slp_tree would need to check whether it was the
last entry into a cycle which would be quite expensive.

Tracking cycle [entries] separately is somewhat difficult since via
vectorizable_* we can later break cycles at arbitrary places so we can't
use weak references for backedges because what and what is not a backedge
can change.

[Bug tree-optimization/97630] [11 Regression] SLP vectorizer leaks memory

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97630

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:feb93adf76eda52385a73eb57c5bef7c870a2564

commit r11-5661-gfeb93adf76eda52385a73eb57c5bef7c870a2564
Author: Richard Biener <rguenther@suse.de>
Date:   Wed Dec 2 14:43:59 2020 +0100

    tree-optimization/97630 - fix SLP cycle memory leak

    This fixes SLP cycles leaking memory by maintaining a double-linked
    list of allocatd SLP nodes we can zap when we free the alloc pool.

    2020-12-02  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/97630
            * tree-vectorizer.h (_slp_tree::next_node,
            _slp_tree::prev_node): New.
            (vect_slp_init): Declare.
            (vect_slp_fini): Likewise.
            * tree-vectorizer.c (vectorize_loops): Call vect_slp_init/fini.
            (pass_slp_vectorize::execute): Likewise.
            * tree-vect-slp.c (vect_slp_init): New.
            (vect_slp_fini): Likewise.
            (slp_first_node): New global.
            (_slp_tree::_slp_tree): Link node into the SLP tree list.
            (_slp_tree::~_slp_tree): Delink node from the SLP tree list.

[Bug tree-optimization/97630] [11 Regression] SLP vectorizer leaks memory

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97630

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.