https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56113
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2019-07-12 00:00:00 |2023-5-4
Keywords|alias |
--- Comment #40 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 4.8.5:
parser function body : 225.66 (15%) usr 2.48 (54%) sys 228.54 (16%) wall
106264 kB ( 4%) ggc
dominator optimization : 162.90 (11%) usr 0.20 ( 4%) sys 163.21 (11%) wall
84375 kB ( 4%) ggc
tree loop invariant motion: 338.05 (23%) usr 0.01 ( 0%) sys 338.28 (23%)
wall 0 kB ( 0%) ggc
1463.11user 4.62system 24:28.53elapsed 99%CPU (0avgtext+0avgdata
3079920maxresident)k
26096inputs+0outputs (12major+631840minor)pagefaults 0swaps
GCC 13.1:
parser function body : 721.25 ( 74%) 3.36 ( 54%) 725.07 ( 74%)
203M ( 8%)
977.96user 6.37system 16:24.91elapsed 99%CPU (0avgtext+0avgdata
3468252maxresident)k
69024inputs+0outputs (104major+1015878minor)pagefaults 0swaps
so overall things improved but the issue in the parser is still present.
Peak memory use also regressed somewhat (but the GCC binary itself is
a lot larger).
On trunk it's really only the frontend. I believe we might have a duplicate
for this particular issue.
