public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "qinzhao at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/111523] Unexpected performance regression with -ftrivial-auto-var-init=zero for e.g. systemctl unmask Date: Thu, 29 Feb 2024 19:19:43 +0000 [thread overview] Message-ID: <bug-111523-4-r644MHoq1k@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-111523-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111523 qinzhao at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |qinzhao at gcc dot gnu.org --- Comment #2 from qinzhao at gcc dot gnu.org --- (In reply to Hans-Peter Nilsson from comment #0) thanks for filing this bug, and sorry for the late reply (I might miss the original notification of this bug when it was opened last year) from the description of the bug, it's not very clear on how to reproduce the performance regression step by step. As a compiler engineer working in performance analysis for quite some years, I suggest to use some performance analysis tools to locate the exact routines in systemd that contribute to the regression. After these specific routines that contribute to the major regression are identified, we can further narrow down to the root cause, usually the following possibilities: 1. some large local array or local structure were initialized by this option, the additional initialization insns cannot be eliminated by compiler optimization. if this is the case, we can add the following attribute: "uninitialized This attribute, attached to a variable with automatic storage, means that the variable should not be automatically initialized by the compiler when the option -ftrivial-auto-var-init presents. " to prevent those local array or structure variables from auto-initialization. 2. there are some missing compiler optimization opportunities which should be enabled to eliminate the overhead.
next prev parent reply other threads:[~2024-02-29 19:19 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-09-21 16:40 [Bug middle-end/111523] New: " hp at gcc dot gnu.org 2023-09-21 16:49 ` [Bug middle-end/111523] " sjames at gcc dot gnu.org 2024-02-29 19:19 ` qinzhao at gcc dot gnu.org [this message] 2024-03-01 0:12 ` sjames at gcc dot gnu.org 2024-03-01 1:25 ` pinskia at gcc dot gnu.org 2024-03-01 5:15 ` pinskia at gcc dot gnu.org 2024-03-01 7:57 ` pinskia at gcc dot gnu.org 2024-03-01 8:23 ` pinskia at gcc dot gnu.org 2024-03-01 8:38 ` pinskia at gcc dot gnu.org 2024-03-07 6:45 ` pinskia at gcc dot gnu.org 2024-03-13 14:01 ` qinzhao at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-111523-4-r644MHoq1k@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).