[Bug tree-optimization/99510] New: [11 Regression] Compile time hog in build_aligned_type since r11-7123-g63538886d1f7fc7c

[Bug tree-optimization/99510] New: [11 Regression] Compile time hog in build_aligned_type since r11-7123-g63538886d1f7fc7c

[marxin at gcc dot gnu.org]

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

            Bug ID: 99510
           Summary: [11 Regression] Compile time hog in build_aligned_type
                    since r11-7123-g63538886d1f7fc7c
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Keywords: compile-time-hog
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

I noticed that here:
https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=226.764.8&plot.1=14.764.8&

$ gfortran -c ./polyhedron/lin/source/doduc.f90 -Ofast -march=znver2

takes now very long time.

[Bug tree-optimization/99510] [11 Regression] Compile time hog in build_aligned_type since r11-7123-g63538886d1f7fc7c

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-03-10
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
      Known to fail|                            |11.0
   Target Milestone|---                         |11.0
      Known to work|                            |10.2.0

[Bug tree-optimization/99510] [11 Regression] Compile time hog in build_aligned_type since r11-7123-g63538886d1f7fc7c

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.

 tree slp vectorization             :  32.83 ( 84%)   0.05 ( 20%)  32.90 ( 83%)
   62M ( 24%)

I suspect it's latent before and caused by excessive vector size iteration.

I'll see what's the real cause here.

[Bug tree-optimization/99510] [11 Regression] Compile time hog in build_aligned_type since r11-7123-g63538886d1f7fc7c

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ah, OK.  We're having a lot of vector CTORs we "vectorize" with load
permutations
like { 484 506 } and that runs into the pre-existing issue (there's a PR
about this...) that we emit dead vector loads for all of the elements in the
group, including gaps.

Costing says they're even which possibly makes sense.

We do a build_aligned_type for each emitted stmt and for some reason
it's quite costly here (well, there's the awkward linear type variant list
to walk ...).

Caching should be possible but the load vectorization loop is already
quite awkward.  Meh.

The rev. likely triggered this because we didn't cost the scalar root
stmt before (the CTOR itself we replace).  Doing that made the costing
profitable.  Having equal scalar and vector load cost makes fixing on
the costing side difficult - the vector load should be an epsilon more
expensive to avoid these issues.

Note for some reason we have gazillion of type variants here.  Huh.
~36070 variants per type.  Ah.  And _that's_ because build_aligned_type does

  for (t = TYPE_MAIN_VARIANT (type); t; t = TYPE_NEXT_VARIANT (t))
    if (check_aligned_type (t, type, align))
      return t;

  t = build_variant_type_copy (type);
  SET_TYPE_ALIGN (t, align);
  TYPE_USER_ALIGN (t) = 1;
^^^^

and check_aligned_type checks for an exact match TYPE_USER_ALIGN, but of
course if 'type' wasn't aligned originally it won't find the created
aligned type ...

Fixing that fixes the compile-time issue.

[Bug tree-optimization/99510] [11 Regression] Compile time hog in build_aligned_type since r11-7123-g63538886d1f7fc7c

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 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:6ceb712e2699a493da544b1755f6f73d62930f9b

commit r11-7596-g6ceb712e2699a493da544b1755f6f73d62930f9b
Author: Richard Biener <rguenther@suse.de>
Date:   Wed Mar 10 11:57:21 2021 +0100

    tree-optimization/99510 - fix type reuse of build_aligned_type

    The fix for PR94775 added more strict checking for type reuse
    to check_aligned_type, specifically matching TYPE_USER_ALIGN.
    But then build_aligned_type sets TYPE_USER_ALIGN on the built
    variant so if the type we build an aligned variant for does not
    have TYPE_USER_ALIGN we'll never re-use the newly created aligned
    variant.  This results in ~35000 identical variants being created
    for polyhedron doduc.

    The following instead checks that the candidate has TYPE_USER_ALIGN set.

    2021-03-10  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/99510
            * tree.c (check_aligned_type): Check that the candidate
            has TYPE_USER_ALIGN set instead of matching with the
            original type.

[Bug tree-optimization/99510] [11 Regression] Compile time hog in build_aligned_type since r11-7123-g63538886d1f7fc7c

[rguenth at gcc dot gnu.org]

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

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

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

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