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.
