https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104203
--- Comment #7 from Martin Sebor <msebor at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
...
> Martin, can you add a new timevar to timevar.def and use that in
> pass_data_waccess please?
Will do. The bottleneck is the PHI handling in the access warning pass:
access analysis : 242.88 ( 75%) 0.02 ( 7%) 243.12 ( 75%)
29k ( 0%)
There are thousands of basic blocks each with thousands of PHI nodes that all
reference each other like this:
<bb 5> [local count: 354193067]:
# v0_3233(ab) = PHI <v0_1065754(D)(ab)(4), v0_3234(ab)(6)>
# v1_4045(ab) = PHI <v1_1065755(D)(ab)(4), v1_4046(ab)(6)>
# v2_4857(ab) = PHI <v2_1065756(D)(ab)(4), v2_4858(ab)(6)>
...
<bb 6> [local count: 177676792]:
# v0_3234(ab) = PHI <v0_1065754(D)(ab)(3), v0_3233(ab)(5), v0_3233(ab)(8),
..., v0_4044(ab)(5251), v0_4044(ab)(5252), v0_4044(ab)(5253)>
# v1_4046(ab) = PHI <v1_1065755(D)(ab)(3), v1_4045(ab)(5), v1_4045(ab)(8),
..., v1_4856(ab)(5251), v1_4856(ab)(5252), v1_4856(ab)(5253)>
...
The access pass has a limit on recursive PHIs but none on this sort of thing.
Let me see what might be a good way to detect this pattern and limit the
processing.
>
> Note with -w the compile-time regression is _not_ fixed. We have
>
> bool
> pass_waccess::gate (function *)
> {
> return (warn_free_nonheap_object
> || warn_mismatched_alloc
> || warn_mismatched_new_delete);
> }
>
> but it seems -w doesn't disable those? Only -Wno-free-nonheap-object works
> here :/ (I guess there might be a bug about -w not disabling warnings
> enabled by default)
Since the pass issues a bunch other warnings (e.g., -Wstringop-overflow,
-Wuse-after-free, etc.) the gate doesn't seem right. But since #pragma GCC
diagnostic can re-enable warnings disabled by -w (or turn them into errors) any
gate that considers the global option setting will also interfere with that.
