From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36408 invoked by alias); 7 Aug 2019 08:54:43 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 36400 invoked by uid 89); 7 Aug 2019 08:54:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=stages, cgraph_node, HX-Languages-Length:2043, office X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Aug 2019 08:54:41 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 8CB78AC20; Wed, 7 Aug 2019 08:54:39 +0000 (UTC) Subject: Re: [PATCH] Detect not-cloned new/delete operators in DCE. To: Martin Jambor , Marc Glisse Cc: "H.J. Lu" , David Malcolm , GCC Patches , Richard Biener , dominik.infuehr@theobroma-systems.com, Jan Hubicka References: <8305B5F4-2A96-4698-8C2E-3255658B5C12@theobroma-systems.com> <20171129083045.GX2353@tucnak> <1511972121.27881.39.camel@redhat.com> <0dd24714-1f35-6a80-c607-7c8a332e95b9@suse.cz> <993cd4f8-cc02-6934-b19b-5a313db0475c@suse.cz> <4dcdd0cb-dc8d-73f4-75a2-8ad1e91731fc@suse.cz> <68bad397-25cb-3233-e392-0964e21ccd71@suse.cz> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: <9be27ec3-5589-5752-a945-e026da6c6fdb@suse.cz> Date: Wed, 07 Aug 2019 08:56:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00434.txt.bz2 On 8/6/19 7:02 PM, Martin Jambor wrote: > Hi, > > unfortunately I cannot look into the problem now and I don't have my > phone set up to review patches in a sane way, but to answer your > question below... Thank you Martin for answer. It can definitely wait once you're back at the office. > > > On Tue, Aug 06 2019, Martin Liška wrote: >> On 8/6/19 2:42 PM, Martin Liška wrote: > > ... > >>> Hm, strange that the ISRA clones don't have n->clone_of set. It's created here: >>> > ... > >>> >>> @Martin, @Honza: Why do we not set clone_of in this transformation? >> > ...node->clone_of is set only while a clone created in the true IPA > stages has no body on its own and shares the body with the > original. These clones form a tree and their clone_of is cleared when > they get a body. IPA-SRA is not a true IPA pass and the clones it > creates are created with create_clone_with_body (or similarly named) > method which immediately gives them a body, so setting clone_of would be > wrong. (The new IPA-SRA is a true IPA pass and so its clones have phase > when their clone_of is set). > > When an IPA-stage clone gets its body (when it is materialized), > node->former_clone_of gets set to the decl (as opposed to cgraph_node) > of the original node and hopefully create_clone_with_body sets it > too. Can you perhaps use that? > >> If I'm correct cgraph_node::clone is used for inline clones only? >> > > IPA-CP also creates clones, it does so by calling > cgraph_node::create_virtual_clone but that also sets clone_of. Hm, I can see neither of cgraph_node::clone_of and cgraph_node::former_clone_of set for my ISRA clone: grep clone /tmp/node next_sibling_clone = , prev_sibling_clone = , clones = , clone_of = , former_clone_of = , simdclone = 0x0, simd_clones = , clone = { tm_clone = 0, Anyway, I'm planning to use DECL_ABSTRACT_ORIGIN here. Martin > > Martin >