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

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #12)
> 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).

If there were a lot of aliasing it were faster ;)  We spend the time
disambiguating (with success).  Alias stmt walking can be attributed to
FRE, PRE, DCE, DSE and some IPA code.  All but the IPA use is throttled
(but that doesn't mean it can use quite some time in some cases).

I have a local modification to how timevars are accounted (accounting nested
sub-systems to individual passes as well, so overall sum doesn't add up to
100% but sth larger).  That, with an unoptimized compiler and -fno-checking
turns up

 alias stmt walking      :  50.53 (68%) usr   0.06 (46%) sys  50.45 (68%) wall 
     2 kB ( 0%) ggc
 tree PRE                :   3.40 ( 5%) usr   0.02 (15%) sys   3.42 ( 5%) wall 
  3579 kB ( 2%) ggc
 tree FRE                :  48.79 (65%) usr   0.05 (38%) sys  48.79 (65%) wall 
   364 kB ( 0%) ggc
 tree DSE                :   1.89 ( 3%) usr   0.00 ( 0%) sys   1.89 ( 3%) wall 
     0 kB ( 0%) ggc

so it's FRE to blame (surprisingly PRE which runs ontop of the FRE engine
is way down here).  I will investigate a bit.

> 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.