[Bug tree-optimization/101014] New: [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[Bug tree-optimization/101014] New: [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[marxin at gcc dot gnu.org]

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

            Bug ID: 101014
           Summary: [12 Regression] Big compile time hog with -O3 since
                    r12-1268-g9858cd1a6827ee7a
           Product: gcc
           Version: 12.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: aldyh at gcc dot gnu.org, amacleod at redhat dot com
  Target Milestone: ---

Created attachment 50978
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50978&action=edit
testcase

Noticed in a yarpget test-case and WRF for instance.
-O3 runs really slowly

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |tnfchris at gcc dot gnu.org
   Last reconfirmed|                            |2021-06-10
   Target Milestone|---                         |12.0
             Status|UNCONFIRMED                 |NEW
      Known to fail|                            |12.0
      Known to work|                            |11.1.0

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |needs-reduction

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
I'm reducing the test-case now..

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Unfortunately, the reduction is stuck at 200KB. Please let me know if you can
analyze the original test-case?

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[amacleod at redhat dot com]

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

Andrew Macleod <amacleod at redhat dot com> changed:

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

--- Comment #3 from Andrew Macleod <amacleod at redhat dot com> ---
Yeah thats fine, I'll look at the original.

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[amacleod at redhat dot com]

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

--- Comment #4 from Andrew Macleod <amacleod at redhat dot com> ---
When a range is being calculated for an ssa-name, the propagation process often
goes along back edges. These back edges sometime require other ssa-names which
have not be processed yet. These are flagged as "poor values" and when
propagation is done, we visit the list of poor values, calculate them, and see
if that may result if a better range for the original ssa-name. 

The problem is that calculating these poor values may also spawn another set of
requests since the block at the far end of the back edge has not been processed
yet... its highly likely that some additional unprocessed ssa-names are used in
the calculation of that name, but typically they do not affect the current
range in a significant way. 

Thus we mostly we care about the first order effect only.  It turns out to be
very rare that a 2nd order effect on a back edge affects anything that we don't
catch later. 

This patch turns off poor-value tagging when looking up the first order values,
thus avoiding the 2nd order and beyond cascading effects.

I haven't found a test case we miss yet because of this change, yet it probably
resolves a number of the outstanding compilation problems in a significant way.

I think this will probably apply to gcc 11 in some form as well, so I'll look
at an equivalent patch for there.

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška <marxin at gcc dot gnu.org> ---
Should be fixed with:

commit ecc5644fa3bc7f37eada2a3e9c627cd1918922e0
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Mon Jun 14 15:33:59 2021 -0400

    Limit new value calculations to first order effects.

    When utilzing poor values during propagation, we mostly care about values
that
    were undefined/processed directly used in calcualting the SSA_NAME being
    processed.  2nd level derivations of such poor values rarely affect the
    inital calculation.  Leave them to when they are directly encountered.

            * gimple-range-cache.cc (ranger_cache::ranger_cache): Adjust.
            (ranger_cache::enable_new_values): Set to specified value and
            return the old value.
            (ranger_cache::disable_new_values): Delete.
            (ranger_cache::fill_block_cache): Disable non 1st order derived
            poor values.
            * gimple-range-cache.h (ranger_cache): Adjust prototypes.
            * gimple-range.cc (gimple_ranger::range_of_expr): Adjust.

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[amacleod at redhat dot com]

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

Andrew Macleod <amacleod at redhat dot com> changed:

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

--- Comment #6 from Andrew Macleod <amacleod at redhat dot com> ---
I swear I put that text in and moved this to resolved... :-(  sigh. sorry.

Anyway, this does not appear to be an issue in GCC 11.. the effect appears to
have been magnified by the new aggressive import/export calculation code in the
GORI rework.

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[marxin at gcc dot gnu.org]

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

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

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

--- Comment #7 from Martin Liška <marxin at gcc dot gnu.org> ---
I'm sorry, but the compile-time hog is still not resolved. I can still see it
in cam4 SPEC benchmark and I'm attaching one another yarpgen test-case.

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
Created attachment 51027
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51027&action=edit
Another test-case

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Macleod <amacleod@gcc.gnu.org>:

https://gcc.gnu.org/g:870b674f72d4894b94efa61764fd87ecec29ffde

commit r12-1652-g870b674f72d4894b94efa61764fd87ecec29ffde
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Fri Jun 18 12:33:18 2021 -0400

    Remove poor value computations.

    Remove the old "poor value" approach which made callbacks into ranger
    from the cache.  Use only the best available value for all propagation.

            PR tree-optimization/101014
            * gimple-range-cache.cc (ranger_cache::ranger_cache): Remove poor
            value list.
            (ranger_cache::~ranger_cache): Ditto.
            (ranger_cache::enable_new_values): Delete.
            (ranger_cache::push_poor_value): Delete.
            (ranger_cache::range_of_def): Remove poor value processing.
            (ranger_cache::entry_range): Ditto.
            (ranger_cache::fill_block_cache): Ditto.
            * gimple-range-cache.h (class ranger_cache): Remove poor value
members.
            * gimple-range.cc (gimple_ranger::range_of_expr): Remove call.
            * gimple-range.h (class gimple_ranger): Adjust.

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[amacleod at redhat dot com]

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

Andrew Macleod <amacleod at redhat dot com> changed:

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

--- Comment #10 from Andrew Macleod <amacleod at redhat dot com> ---
Really fixed this time.

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[crazylht at gmail dot com]

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

Hongtao.liu <crazylht at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |crazylht at gmail dot com

--- Comment #11 from Hongtao.liu <crazylht at gmail dot com> ---
I'm not sure if it's related but compilation of 527.cam4_r still hangs with

gcc version 12.0.0 20210621 (experimental) (GCC) 

and option:

-march=cascadelake -Ofast -funroll-loops -flto -g -mfpmath=sse

hang on this thread for more than 2h.

liuhongt  79919  79918 99 15:52 pts/4    00:50:13
/export/users2/liuhongt/install/gnu-toolchain_master/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto1
-march=cascadelake -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2
-mavx -mavx2 -mno-sse4a -mno-fma4 -mno-xop -mfma -mavx512f -mbmi -mbmi2 -maes
-mpclmul -mavx512vl -mavx512bw -mavx512dq -mavx512cd -mno-avx512er
-mno-avx512pf -mno-avx512vbmi -mno-avx512ifma -mno-avx5124vnniw
-mno-avx5124fmaps -mno-avx512vpopcntdq -mno-avx512vbmi2 -mno-gfni
-mno-vpclmulqdq -mavx512vnni -mno-avx512bitalg -mno-avx512bf16
-mno-avx512vp2intersect -mno-3dnow -madx -mabm -mno-cldemote -mclflushopt
-mclwb -mno-clzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr -mhle -msahf
-mno-lwp -mlzcnt -mmovbe -mno-movdir64b -mno-movdiri -mno-mwaitx -mno-pconfig
-mpku -mno-prefetchwt1 -mprfchw -mno-ptwrite -mno-rdpid -mrdrnd -mrdseed -mrtm
-mno-serialize -mno-sgx -mno-sha -mno-shstk -mno-tbm -mno-tsxldtrk -mno-vaes
-mno-waitpkg -mno-wbnoinvd -mxsave -mxsavec -mxsaveopt -mxsaves -mno-amx-tile
-mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset -mno-kl -mno-widekl
-mno-avxvnni -quiet -dumpbase ./cam4_r.ltrans43.ltrans -mmmx -mpopcnt -msse
-msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -mno-sse4a -mno-fma4
-mno-xop -mfma -mavx512f -mbmi -mbmi2 -maes -mpclmul -mavx512vl -mavx512bw
-mavx512dq -mavx512cd -mno-avx512er -mno-avx512pf -mno-avx512vbmi
-mno-avx512ifma -mno-avx5124vnniw -mno-avx5124fmaps -mno-avx512vpopcntdq
-mno-avx512vbmi2 -mno-gfni -mno-vpclmulqdq -mavx512vnni -mno-avx512bitalg
-mno-avx512bf16 -mno-avx512vp2intersect -mno-3dnow -madx -mabm -mno-cldemote
-mclflushopt -mclwb -mno-clzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr
-mhle -msahf -mno-lwp -mlzcnt -mmovbe -mno-movdir64b -mno-movdiri -mno-mwaitx
-mno-pconfig -mpku -mno-prefetchwt1 -mprfchw -mno-ptwrite -mno-rdpid -mrdrnd
-mrdseed -mrtm -mno-serialize -mno-sgx -mno-sha -mno-shstk -mno-tbm
-mno-tsxldtrk -mno-vaes -mno-waitpkg -mno-wbnoinvd -mxsave -mxsavec -mxsaveopt
-mxsaves -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset
-mno-kl -mno-widekl -mno-avxvnni -mtune=cascadelake -mfpmath=sse -m64
-mfpmath=sse -g -g -Ofast -Ofast -fno-openmp -fno-openacc -fno-pie
-fcf-protection=none -funroll-loops -fno-associative-math -fltrans
@/tmp/cctsotsZ -o /tmp/ccjbpUzj.s

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[aldyh at gcc dot gnu.org]

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

--- Comment #12 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Hongtao.liu from comment #11)
> I'm not sure if it's related but compilation of 527.cam4_r still hangs with
> 
> gcc version 12.0.0 20210621 (experimental) (GCC) 

Can you verify after which patch upstream it started hanging?  It may or may
not be related to this bug.

Or perhaps, can you check where it hangs?  Is it hanging in the ranger code or
elsewhere?

Thanks.

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[crazylht at gmail dot com]

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

--- Comment #13 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Aldy Hernandez from comment #12)
> (In reply to Hongtao.liu from comment #11)
> > I'm not sure if it's related but compilation of 527.cam4_r still hangs with
> > 
> > gcc version 12.0.0 20210621 (experimental) (GCC) 
> 
> Can you verify after which patch upstream it started hanging?  It may or may
> not be related to this bug.
> 
> Or perhaps, can you check where it hangs?  Is it hanging in the ranger code
> or elsewhere?

After hanging for 36m, with gdb -p pid

(gdb) bt
#0  0x0000000001035810 in irange::varying_compatible_p
(this=this@entry=0x7ffdd7672630)
    at /export/users2/liuhongt/gcc/gnu-toolchain/master/gcc/value-range.h:289
#1  0x000000000102a08b in irange::normalize_kind (this=0x7ffdd7672630)
    at /export/users2/liuhongt/gcc/gnu-toolchain/master/gcc/value-range.h:584
#2  irange::irange_set (this=0x7ffdd7672630, min=<optimized out>,
max=<optimized out>)
    at /export/users2/liuhongt/gcc/gnu-toolchain/master/gcc/value-range.cc:182
#3  0x000000000102922c in range_query::get_tree_range (this=0x2614590
<global_ranges>, r=..., expr=0x148092cd3de0, stmt=0x148092896738)
    at /export/users2/liuhongt/gcc/gnu-toolchain/master/gcc/value-query.cc:212
#4  0x000000000175457e in fold_using_range::range_of_range_op (this=<optimized
out>, r=..., s=0x148092896738, src=...)
    at /export/users2/liuhongt/gcc/gnu-toolchain/master/gcc/gimple-range.cc:642
#5  0x0000000001757606 in fold_using_range::fold_stmt (this=0x7ffdd76736cf,
r=..., s=0x148092896738, src=..., name=0x1480925eae10)
    at /export/users2/liuhongt/gcc/gnu-toolchain/master/gcc/gimple-range.cc:577
#6  0x000000000175795d in fold_range (r=..., s=s@entry=0x148092896738,
q=<optimized out>)
    at /export/users2/liuhongt/gcc/gnu-toolchain/master/gcc/gimple-range.cc:312
#7  0x000000000175a5d3 in ranger_cache::range_of_def (this=0x7ffdd7687950,
r=..., name=0x1480925eae10, bb=0x0)
    at
/export/users2/liuhongt/gcc/gnu-toolchain/master/gcc/gimple-range-cache.cc:842
#8  0x000000000175a690 in ranger_cache::entry_range (this=0x7ffdd7687950,
r=..., name=0x1480925eae10, bb=0x148092bffbc8)
    at
/export/users2/liuhongt/gcc/gnu-toolchain/master/gcc/gimple-range-cache.cc:866
#9  0x000000000175a796 in ranger_cache::range_of_expr (this=<optimized out>,
r=..., name=<optimized out>, stmt=<optimized out>)
    at
/export/users2/liuhongt/gcc/gnu-toolchain/master/gcc/gimple-range-cache.cc:914
#10 0x000000000175faaa in gori_compute::compute_operand1_range
(this=0x7ffdd76879d0, r=..., stmt=0x14809245bb40, lhs=..., 
    name=0x1480932cf9d8, src=...) at
/export/users2/liuhongt/gcc/gnu-toolchain/master/gcc/gimple-range-gori.cc:877
#11 0x000000000176083a in gori_compute::compute_operand_range (src=...,
name=0x1480932cf9d8, lhs=..., stmt=0x14809245bb40, r=..., 
    this=0x7ffdd76879d0) at
/export/users2/liuhongt/gcc/gnu-toolchain/master/gcc/gimple-range-gori.cc:620
#12 gori_compute::outgoing_edge_range_p (this=this@entry=0x7ffdd76879d0, r=...,
e=e@entry=0x14809234a750, name=name@entry=0x1480932cf9d8, 
    q=...) at
/export/users2/liuhongt/gcc/gnu-toolchain/master/gcc/gimple-range-gori.cc:1044
#13 0x000000000175ae00 in ranger_cache::propagate_cache (this=0x7ffdd7687950,
name=0x1480932cf9d8)
    at
/export/users2/liuhongt/gcc/gnu-toolchain/master/gcc/gimple-range-cache.cc:1027
#14 0x000000000175b4e7 in ranger_cache::fill_block_cache (this=0x7ffdd7687950,
name=0x1480932cf9d8, bb=<optimized out>, 
    def_bb=0x1480933e5ea0) at
/export/users2/liuhongt/gcc/gnu-toolchain/master/gcc/gimple-range-cache.cc:1238
#15 0x000000000175b980 in ranger_cache::block_range (this=0x7ffdd7687950,
r=..., bb=0x148092c4e680, name=0x1480932cf9d8, 
    calc=<optimized out>) at
/export/users2/liuhongt/gcc/gnu-toolchain/master/gcc/gimple-range-cache.cc:971
#16 0x0000000001753a92 in gimple_ranger::range_on_entry (this=0x7ffdd7687940,
r=..., bb=0x148092c4e680, name=0x1480932cf9d8)
    at
/export/users2/liuhongt/gcc/gnu-toolchain/master/gcc/gimple-range.cc:1203
#17 0x0000000001757cef in gimple_ranger::range_of_expr (this=<optimized out>,
r=..., expr=0x1480932cf9d8, stmt=<optimized out>)
    at
/export/users2/liuhongt/gcc/gnu-toolchain/master/gcc/gimple-range.cc:1186

> 
> Thanks.

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
I can confirm this and I've opened PR101148 for this.

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[marxin at gcc dot gnu.org]

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

--- Comment #15 from Martin Liška <marxin at gcc dot gnu.org> ---
Created attachment 51043
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51043&action=edit
One another test-case

I have one more test-case that hangs with -O3.

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[marxin at gcc dot gnu.org]

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

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

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

--- Comment #16 from Martin Liška <marxin at gcc dot gnu.org> ---
Reopenning.

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[amacleod at redhat dot com]

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

--- Comment #17 from Andrew Macleod <amacleod at redhat dot com> ---
Created attachment 51050
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51050&action=edit
patch to fix the issue

The gift that keeps on giving eh.
OK, this should solve the infinite loop. Give it a try, I'm running it through
testing now.

When I introduced the sparse on-entry cache, it is limited to 15 unique ranges
for any given ssa-name, then  it reverts to varying for any additional values
to be safe.

The cache propagation engine works by combining incoming ranges and if that is
different than that current on-entry range, stores that  and proceeds to push
this new value on outgoing edges.

What was happening here is this new value that was calculated was beyond the 15
allowed. When it was stored, it was stored as VARYING.  This block was in a
cycle feeding back to itself, so when it calculated the on-enty value again and
compared, it though it needed to update again.  Which of course failed again...
and the endless loop of trying to propagate was born.

This patch checks that the value being stored to the cache is the same as the
value when it is immediately reloaded. If that fails, we stop trying to
propagate that value.

Please check that it solves both this problam, and likely the 101148 problem

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[marxin at gcc dot gnu.org]

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

--- Comment #18 from Martin Liška <marxin at gcc dot gnu.org> ---
Thank you for the patch. I can confirm it fixes both the attached yarpgen
test-case and cam4 finishes (PR101148).

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[cvs-commit at gcc dot gnu.org]

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

--- Comment #19 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Macleod <amacleod@gcc.gnu.org>:

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

commit r12-1750-ga03e944e92ee51ae583382079d4739b64bd93b35
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Tue Jun 22 17:46:05 2021 -0400

    Do not continue propagating values which cannot be set properly.

    If the on-entry cache cannot properly represent a range, do not continue
    trying to propagate it.

            PR tree-optimization/101148
            PR tree-optimization/101014
            * gimple-range-cache.cc (ranger_cache::ranger_cache): Adjust.
            (ranger_cache::~ranger_cache): Adjust.
            (ranger_cache::block_range): Check if propagation disallowed.
            (ranger_cache::propagate_cache): Disallow propagation if new value
            can't be stored properly.
            * gimple-range-cache.h (ranger_cache::m_propfail): New member.

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[amacleod at redhat dot com]

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

Andrew Macleod <amacleod at redhat dot com> changed:

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

--- Comment #20 from Andrew Macleod <amacleod at redhat dot com> ---
Hopefully this closes it for good.  The final patch needed to adjust the
propagation engine to avoid propagating the failed value more than once.  The
original patch simply stopped propagating immediately, and that caused other
issues.

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[cvs-commit at gcc dot gnu.org]

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

--- Comment #21 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Andrew Macleod
<amacleod@gcc.gnu.org>:

https://gcc.gnu.org/g:85c22c517e9571d1f0f487fd708fbb01f36f172a

commit r11-8750-g85c22c517e9571d1f0f487fd708fbb01f36f172a
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Tue Jun 22 17:46:05 2021 -0400

    Do not continue propagating values which cannot be set properly.

    If the on-entry cache cannot properly represent a range, do not continue
    trying to propagate it.

            PR tree-optimization/101148
            PR tree-optimization/101014
            * gimple-range-cache.cc (ranger_cache::ranger_cache): Adjust.
            (ranger_cache::~ranger_cache): Adjust.
            (ranger_cache::block_range): Check if propagation disallowed.
            (ranger_cache::propagate_cache): Disallow propagation if new value
            can't be stored properly.
            * gimple-range-cache.h (ranger_cache::m_propfail): New member.