From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id EB1303858C74; Wed, 21 Sep 2022 11:18:09 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EB1303858C74
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1663759089;
	bh=542sGhMPMDf1AtLbqcNLijBBARoxPOmLYm3jmji+FBo=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=NI/DIFlPcHdVc6pUX9yBAcjIyyUqPO/PP9aWO2vZzNIx+8b/dPKmXJ5urq2cIAYun
	 KHo0h+Xtlw+so6gCM4abN5GuvicaCJgybMMPUuTaL35nB01bsT9B6rU1ENjrfl6YLZ
	 +82FH4rFT0oyaysPnapjvOmDUqGWFjomSFqfivaE=
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
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hubicka at ucw dot cz
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-106991-4-R5EFcOGaab@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106991-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106991-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- 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.
>=20
> 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=