[Bug rtl-optimization/59811] [4.9/5/6 Regression] Huge increase in memory usage and compile time in combine

[law at redhat dot com]

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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com

--- Comment #12 from Jeffrey A. Law <law at redhat dot com> ---
So Jan fixed the combine issue when he committed his changes to remove
statements which set write-only variables.  That essentially brought the
combiner down to nothing.  Hard to believe since it was just a dozen or so
nodes that were determined to be write-only.  But that was double-checked by
just hacking out the call to set_writeonly_bit in one of the older compilers I
was testing.

Richi's change to improve DOM's handling of aliased loads helps considerably if
someone were to disable the IPA propagation bits.

Unfortunately we're still burning a lot of time in the alias walking.  So we
can't reasonably consider this resolved for gcc-6:


 alias stmt walking      :  38.67 (64%) usr   0.01 ( 7%) sys  38.64 (64%) wall 
     2 kB ( 0%) ggc
 tree copy propagation   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
     0 kB ( 0%) ggc
 combiner                :   0.35 ( 1%) usr   0.01 ( 7%) sys   0.36 ( 1%) wall 
  2709 kB ( 2%) ggc
 integrated RA           :   2.27 ( 4%) usr   0.00 ( 0%) sys   2.31 ( 4%) wall 
  6634 kB ( 4%) ggc
 LRA hard reg assignment :   4.39 ( 7%) usr   0.01 ( 7%) sys   4.41 ( 7%) wall 
     0 kB ( 0%) ggc

The alias statement walking is a bit surprising.  This is Fortran code after
all, I wouldn't expect a lot of aliasing, I guess it's just a lot of calls into
the alias statement walking code (but I haven't looked to confirm that theory).

I think the RA/LRA times are probably worth some investigation as well once we
get a handle on what's causing alias stmt walking to go nuts.