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.

  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: link
Be 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).