From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6556 invoked by alias); 27 May 2015 21:36:11 -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 6540 invoked by uid 89); 27 May 2015 21:36:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 27 May 2015 21:36:10 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id C148D5408B4; Wed, 27 May 2015 23:36:06 +0200 (CEST) Date: Thu, 28 May 2015 00:26:00 -0000 From: Jan Hubicka To: Richard Biener Cc: Jan Hubicka , gcc-patches@gcc.gnu.org, mliska@suse.cz Subject: Re: Add few cases to operand_equal_p Message-ID: <20150527213606.GG88897@kam.mff.cuni.cz> References: <20150522123341.GD91616@kam.mff.cuni.cz> <20150522135025.GE75713@kam.mff.cuni.cz> <20150526173022.GC43680@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-05/txt/msg02583.txt.bz2 > Yes, so this shows using original bodies for inlining isn't the issue. > The issue is that we can't really ignore TBAA (completely?) when > merging function bodies, independent of any issues that pop up > when inlining merged bodies. We should have the above as testcase Yes. > in the testsuite (with both source orders of a and b to make sure > ICF will eventually pick both). > > Now the question is whether we can in some way still merge the above > two functions and retain (some) TBAA, like by making sure to adjust > all MEM_REFs to use union { type1; type2; } for the TBAA type... (eh). I discussed the plan with Martin. I think the first step would be to make this work at -Os in the following way 1) we will do unification ignoring alias sets completely 2) once equivalneces are stablished we verify what can be unified (icf_merge is not always doable) and fix the unification decisions. 3) For every function that remains in the program we produce list of other functions that was merged into it. For each of it we make sure that alias sets are conservative dropping to 0 where neccesary. 4) we apply the redirectinos and throw away original bodies (or keep them for inlining to improve debug info) This scheme is useful to merge other metadata, too (such as jump functions). Now for -O2 it will be harder to decide whether punt merging or drop alias set. We can even introduce the artificial union (as alias sets only or as types themselves) and do just as much of TBAA punting as needed. But I would build from experience above. > > No longer globbing all pointer types will even make std::vector > no longer mergeable... Yep, we do not merge most of tyime anyway, as eventually ipa-icf gets sily enough to compare the pointed-to type or it tries to match FIELD_DECL references exactly. I plan to slowly work on that once we settle down currently open topics ;) Honza > > Richard. > > > > > > > > I also do not believe that TBAA should be function local. I believe it is > > > > useful to propagate stuff interprocedurally, like ipa-prop could be able to > > > > propagate this: > > > > > > > > long *ptr1; > > > > int *ptr2; > > > > t(int *ptr) > > > > { > > > > return *ptr; > > > > } > > > > wrap(int *ptr) > > > > { > > > > *ptr1=1; > > > > } > > > > call() > > > > { > > > > return wrap (*ptr2); > > > > } > > > > > > > > and we could have ipa-reference style pass that collect alias sets > > > > read/written by a function and uses it during local optimization to > > > > figure out if there is a true dependence between function call and > > > > memory store. > > > > > > Sure, but after ICF there is no IPA propagation... > > Doesn't matter if you propagate before or after ICF. If you do before, ICF > > would need to match/merge the alias set in optimization summary to be sure that > > the functions are same. > > > > Honza > > > > > > Richard. > > > > > > -- > > > Richard Biener > > > SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg) > > > > > > -- > Richard Biener > SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg)