From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102641 invoked by alias); 5 Aug 2016 11:36:53 -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 102626 invoked by uid 89); 5 Aug 2016 11:36:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= 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; Fri, 05 Aug 2016 11:36:50 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id CFA07543CDC; Fri, 5 Aug 2016 13:36:44 +0200 (CEST) Date: Fri, 05 Aug 2016 11:36:00 -0000 From: Jan Hubicka To: kugan Cc: Jan Hubicka , Richard Biener , Prathamesh Kulkarni , Martin Jambor , gcc Patches Subject: Re: [RFC] ipa bitwise constant propagation Message-ID: <20160805113644.GD37215@kam.mff.cuni.cz> References: <20160804130549.GA77269@kam.mff.cuni.cz> <2ae790a8-c30b-bbcc-9d8d-db60f10f9d87@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2ae790a8-c30b-bbcc-9d8d-db60f10f9d87@linaro.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2016-08/txt/msg00441.txt.bz2 > Hi Honza, > > On 04/08/16 23:05, Jan Hubicka wrote: > >>I didn't look at the propagation part but eventually the IPA-CP > >>lattice gets quite big. Also the alignment lattice is very > >>similar to the bits lattice so why not merge those two? But > > > >This was always the original idea to replace alignment propagation by bitwise > >ccp. I suppose we only have issue here because nonzero bits are not tracked for > >pointers so we need to feed the original lattices by hand? > > I also raised this one with Prathamesh off line. With the early-vrp, > we should have nonzero_bits for non pointers. For pointers we should > feed the lattices with get_pointer_alignment_1 as it is done in > ipa-cpalignment propagation. Yes, that is the general idea. Note that also for pointers it would be very useful to track what pointers are non-NULL (C++ multiple inheritance inserts a lot of NULL pointer checks that confuse us in later analysis and it would be nice to optimize them out). I am not very convinced saving a pointer is worth to make difference between pointers/nonpointers for all the local tracking. > > >We could also make use of VR ranges and bits while evaultaing predicates > >in ipa-inline-analysis. I can look into it after returning from Leeds. > > Indeed. With ealrly dom based VRP (non iterative at this point), > some of the ranges can be pessimistic and can impact the estimation. > Let me have a look at this. Yes, but those are independent issues - size/time estimates should take into account the new info we have and we should work on getting it better when we can ;) I will try to revisit the size/time code after returning from my vacation and turn it into sreals for time + cleanup/generalize the APIs a bit. I tried to do it last stage1 but got stuck on some of ugly side cases + gengtype not liking sreal type. Honza > > Thanks, > Kugan >