From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50964 invoked by alias); 14 Mar 2017 10:09:35 -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 50944 invoked by uid 89); 14 Mar 2017 10:09:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1018, UD:local X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 14 Mar 2017 10:09:33 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 2A61FAAB9; Tue, 14 Mar 2017 10:09:32 +0000 (UTC) Subject: Re: [PATCH 2] Fix multiple target clones nodes (PR lto/66295). To: Richard Biener References: <3fc1a062-956e-ae18-21ff-296685d4f8c8@suse.cz> <2663b3eb-d7ef-e5ca-6d6e-28f6b9f02fc5@suse.cz> Cc: GCC Patches , evstupac@gmail.com, Jan Hubicka From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: <9777dcdc-5c67-e2ad-7832-6fb839a89f27@suse.cz> Date: Tue, 14 Mar 2017 10:09:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00709.txt.bz2 On 03/14/2017 10:46 AM, Richard Biener wrote: > On Mon, Mar 13, 2017 at 4:19 PM, Martin Liška wrote: >> Hello. >> >> This is a small follow-up patch, where local.local flag should be also dropped >> for a default implementation. >> >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. >> >> Ready to be installed? > > I see we have clered the flag on the clones this way. But isn't it > bogus to have > it set in the first place? That is, isn't analysis sofar given bogus info? Yes, I did it for clones. Reason why we mark it is that local flag is set by pass_ipa_function_and_variable_visibility pass, which runs before MV pass. I can imagine MV can bail out for a non-trivial reason and the visibility pass should somehow simulate and predict what happens in the MV pass? Martin > > Shouldn't we instead fix local_p to not mark functions with MV attribute local > in the first place? > > Richard. > >> Martin