From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) by sourceware.org (Postfix) with ESMTPS id CDAF9385BF83 for ; Tue, 7 Apr 2020 11:57:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CDAF9385BF83 Received: by mail-lf1-x142.google.com with SMTP id x23so2162166lfq.1 for ; Tue, 07 Apr 2020 04:57:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C3OumRjvvkaEAebM0ubakb7jP6wtYf0r9pKX4Td/F6o=; b=kzZErPmsYkTlAvVSLkU1qEFlUx2eP+yMaFdRKj7LNE5tcgXVSNBkuFDcG/MZTtznR1 6PfOI+/5SZlt1Cpa0wRLlW6nIOa3lU9sGc3rakJcxBVOYMPNWd+TNps/dNTsKZLxqGKk hHizKr3oQElbeeXePcIAXR+z7K9CRzAdI9ZL6xbBWbezUcx7wTWn/ucXUeLTCXv7J5XZ uod9Quio9S9e/StQOenhMO6pBOp+DBCTo5SwUN0EcW5SUu2uh005hYHVRTM5rOXmpX13 DY4KHxj9nPqCqOlH1v4HjDZUp6yh0oGu/IE/2ra6LMg5noV3nOXzKgLNtRHEhJXMg0LU i/Jw== X-Gm-Message-State: AGi0PuZhpQEiToOuTFavAc4AJI7hBSjU+D/gJqPvYre06SUOKRdqRdpP IdLESiSFhNW/WYoJDy45aJtLG4ELa1wfxyCrfmw= X-Google-Smtp-Source: APiQypLxZxhhghuA5nGfDV6w/y6pcDJaOitW4kaU0tfjqlVXvKWe9dkA//Ldb75Xay9oFaaGD6WCmnw+fKwwWkZEHEI= X-Received: by 2002:a05:6512:478:: with SMTP id x24mr1307186lfd.193.1586260645536; Tue, 07 Apr 2020 04:57:25 -0700 (PDT) MIME-Version: 1.0 References: <20200331122907.GB62067@kam.mff.cuni.cz> <65230a52-c025-a6e3-0d31-409d37e9b2c9@suse.cz> <20200403152609.GA35629@kam.mff.cuni.cz> <0dbc191e-66f7-9878-956d-96149f20f5bf@suse.cz> In-Reply-To: From: Richard Biener Date: Tue, 7 Apr 2020 13:57:13 +0200 Message-ID: Subject: Re: [PATCH] Check DECL_CONTEXT of new/delete operators. To: Jonathan Wakely Cc: Nathan Sidwell , =?UTF-8?Q?Martin_Li=C5=A1ka?= , Jan Hubicka , GCC Patches , Marc Glisse , Jason Merrill Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 11:57:28 -0000 On Tue, Apr 7, 2020 at 1:46 PM Jonathan Wakely wrote: > > On Tue, 7 Apr 2020 at 12:40, Richard Biener wrote: > > > > On Tue, Apr 7, 2020 at 1:30 PM Jonathan Wakely wrote: > > > > > > On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote: > > > > The both operator new and operator delete are looked up in the same > > > > manner. The std does not require a 'matching pair' be found. but it is > > > > extremely poor form for a class to declare exactly one of operator > > > > {new,delete}. > > > > > > There are unfortunately several such example in the standard! > > > > > > I wonder how much benefit we will really get from trying to make this > > > optimisation too general. > > > > > > Just eliding (or coalescing) implicit calls to ::operator new(size_t) > > > and ::operator delete(void*, size_t) (and the [] and align_val_t forms > > > of those) probably covers 99% of real cases. > > > > IIRC the only reason to have the optimization was to fully elide > > STL containers when possible. That brings in allocators and > > thus non ::new/::delete allocations. > > But the vast majority of containers are used with std::allocator, and > we control that. > > Wouldn't it be simpler to add __builtin_operator_new and > __builtin_operator_delete like clang has, then make std::allocator use > those, and limit the optimizations to uses of those built-ins? Sure, that's a viable implementation strathegy. Another might be void delete (void *) __attribute__((matching_new(somewhere::new))); and thus allow the user to relate a new/delete pair (here the FE would do lookup for 'new' and record for example the mangled assembler name). That is, we usually try to design a mechanism that's more broadly usable. But yes, we match malloc/free so matching ::new/::delete by aliasing them to __builtin_operator_new and __builtin_operator_delete is fair enough. Not easily usable by other languages with custom allocation though (fortran allocate/deallocate anyone? that's currently inlined to expose underlying malloc/free calls for similar reasons) Richard.