[Bug debug/52001] New: [4.7 reegression] Huge compile-time regression with var-tracking

[Bug debug/52001] New: [4.7 reegression] Huge compile-time regression with var-tracking

[rsandifo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52001

             Bug #: 52001
           Summary: [4.7 reegression] Huge compile-time regression with
                    var-tracking
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: rsandifo@gcc.gnu.org


r182760 significantly increased the compile time of 20001226-1.c -O3 -g
on mips64-linux-gnu:

time for -O3:
    real    0m25.656s
    user    0m25.106s
    sys     0m0.544s

time for -O3 -g before r182760:
    real    0m28.212s
    user    0m27.586s
    sys     0m0.624s

time for -O3 -g after r182760, CTRL-Ced after:
    real    15m11.725s
    user    15m11.177s
    sys     0m0.496s

The testcase has a lot of identical "load high, add low" sequences.
Even though there are only two values here (the high part and
the result), we end up with thousands of value rtxs and thousands
of distinct "reverse" locations attached to the "load high" value.

c.f.: http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01051.html

[Bug debug/52001] [4.7 reegression] Huge compile-time regression with var-tracking

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52001

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-25 19:27:41 UTC ---
Confirmed, I saw this also with my testing.

[Bug debug/52001] [4.7 reegression] Huge compile-time regression with var-tracking

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52001

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|mipsisa64-elf               |mipsisa64-elf,
                   |                            |mips64-linux-gnu
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-01-25
   Target Milestone|---                         |4.7.0
     Ever Confirmed|0                           |1

[Bug debug/52001] [4.7 Regression] Huge compile-time regression with var-tracking

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52001

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |jakub at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-26 15:50:20 UTC ---
Created attachment 26472
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26472
gcc47-pr52001.patch

Untested fix.  It doesn't make any sense to insert any reverse ops when V is
already known to have a location which is certainly simpler than that and
permanently available through the entire function.

[Bug debug/52001] [4.7 Regression] Huge compile-time regression with var-tracking

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52001

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-27 09:26:53 UTC ---
Author: jakub
Date: Fri Jan 27 09:26:48 2012
New Revision: 183608

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183608
Log:
    PR debug/52001
    * var-tracking.c (reverse_op): Don't add any reverse operation
    if V already has any constant locations.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/var-tracking.c

[Bug debug/52001] [4.7 Regression] Huge compile-time regression with var-tracking

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52001

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-27 09:29:12 UTC ---
Fixed.

[Bug debug/52001] [4.7 Regression] Huge compile-time regression with var-tracking

[aoliva at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52001

--- Comment #5 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-02-25 12:09:33 UTC ---
Author: aoliva
Date: Sat Feb 25 12:09:27 2012
New Revision: 184571

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184571
Log:
PR debug/52001
* cselib.c (preserve_only_constants): Rename to...
(preserve_constants_and_equivs): ... this.  Split out...
(invariant_or_equiv_p): ... this.  Preserve plus expressions
of other preserved expressions too.
(cselib_reset_table): Adjust.
* var-tracking.c (reverse_op): Use canonical value to build
reverse operation.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cselib.c
    trunk/gcc/var-tracking.c

[Bug debug/52001] [4.7 Regression] Huge compile-time regression with var-tracking

[aoliva at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52001

--- Comment #6 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-02-25 12:09:48 UTC ---
Author: aoliva
Date: Sat Feb 25 12:09:41 2012
New Revision: 184572

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184572
Log:
PR debug/52001
* alias.c (refs_newer_value_cb, refs_newer_value_p): New.
(get_addr): Walk canonical value's locs.  Avoid returning VALUEs
and locs that reference values newer than the non-canonical value
at hand.  Return the canonical value as a worst case.
(memrefs_conflict_p): Walk canonical value's locs.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/alias.c

[Bug debug/52001] [4.7 Regression] Huge compile-time regression with var-tracking

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52001

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gjl at gcc dot gnu.org

--- Comment #7 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-02-29 11:30:14 UTC ---
(In reply to comment #6)
> Author: aoliva
> Date: Sat Feb 25 12:09:41 2012
> New Revision: 184572
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184572
> Log:
> PR debug/52001
> * alias.c (refs_newer_value_cb, refs_newer_value_p): New.
> (get_addr): Walk canonical value's locs.  Avoid returning VALUEs
> and locs that reference values newer than the non-canonical value
> at hand.  Return the canonical value as a worst case.
> (memrefs_conflict_p): Walk canonical value's locs.
> 
> Modified:
>     trunk/gcc/ChangeLog
>     trunk/gcc/alias.c

This caused PR52417.

With alias.c at r184571 the compiler does not enter infinite loop.

[Bug debug/52001] [4.7 Regression] Huge compile-time regression with var-tracking

[aoliva at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52001

--- Comment #8 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-03-01 16:58:17 UTC ---
Author: aoliva
Date: Thu Mar  1 16:58:11 2012
New Revision: 184750

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184750
Log:
PR debug/52001
PR rtl-optimization/52417
* cselib.c (cselib_any_perm_equivs): New variable.
(cselib_reset_table): Check that it's not set when not
preserving constants.
(cselib_add_permanent_equiv): Set it.
(cselib_have_permanent_equivalences): New.
(cselib_init, cselib_finish): Reset it.
* cselib.h (cselib_have_permanent_equivalences): Declare.
* alias.c (get_addr): Restore earlier behavior when there
aren't permanent equivalences.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/alias.c
    trunk/gcc/cselib.c
    trunk/gcc/cselib.h