public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "hubicka at ucw dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/106991] new+delete pair not optimized by g++ at -O3 but optimized at -Os
Date: Wed, 21 Sep 2022 11:18:09 +0000	[thread overview]
Message-ID: <bug-106991-4-R5EFcOGaab@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-106991-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106991

--- Comment #2 from Jan Hubicka <hubicka at ucw dot cz> ---
> Looks like inlining decisions decide to inline new but not delete but for -Os
> we inline none and elide the new/delete pair.
> 
> Maybe we can devise some inline hints to keep pairs?

Inliner is mostly built around an assumption that inline decisions are
idnependent on each call site.  It would be possible to add something
like that though: we could add links to inline summaries to hold the
pairs, modify can_inline and want_inline predicates to understand them
and extend inline_call to do both inlines when needed.  It will cause
some fallout since users of inline_call does not expect it to modify
other call sites.

I am not sure how good idea this would be though.  It seems to me that
it makes sense to treat them independently.

The reason we do not inline delete here is that delete used is different
form the one defined. Function calls
  operator delete(void*, unsigned long)
while testcase defines
  operator delete(void*)
Honza

  parent reply	other threads:[~2022-09-21 11:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-21  4:53 [Bug c++/106991] New: " hiraditya at msn dot com
2022-09-21  8:17 ` [Bug ipa/106991] " rguenth at gcc dot gnu.org
2022-09-21 11:18 ` hubicka at ucw dot cz [this message]
2022-09-21 21:37 ` hiraditya at msn dot com

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-106991-4-R5EFcOGaab@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).