From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11090 invoked by alias); 14 Nov 2012 19:42:56 -0000 Received: (qmail 11079 invoked by uid 22791); 14 Nov 2012 19:42:56 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RDNS_NONE,TW_XX X-Spam-Check-By: sourceware.org Received: from Unknown (HELO atrey.karlin.mff.cuni.cz) (195.113.26.193) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Nov 2012 19:42:49 +0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id 15673F085C; Wed, 14 Nov 2012 20:42:42 +0100 (CET) Date: Wed, 14 Nov 2012 19:42:00 -0000 From: Jan Hubicka To: "sergos.gnu at gmail dot com" Cc: gcc-bugs@gcc.gnu.org Subject: Re: [Bug tree-optimization/54717] [4.8 Regression] Runtime regression: polyhedron test "rnflow" degraded Message-ID: <20121114194241.GB13739@atrey.karlin.mff.cuni.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-11/txt/msg01282.txt.bz2 > So for the loop that starting at bb 28 you can see the xxtrt_46 access was not > put into pretemp. Possible reason is exactly as it was mentioned by Richard - > there were extra candidates collected and this one become less anticipatable > > Skipping partial partial redundancy for expression > {array_ref,mem_ref<0B>,xxtrt_46(D)}@.MEM_30(D) (0165) > not partially anticipated on any to be optimized for speed edges > ----------------------------------------------------------------------- > Found partial partial redundancy for expression > {array_ref,mem_ref<0B>,xxtrt_46(D)}@.MEM_30(D) (0165) > Created phi prephitmp_237 = PHI <_88(90), _85(29)> > in block 30 Hmm, interesting, what is the edge resonsible? I would expect it to be the loopback edge and its frequency is: ;; basic block 28, loop depth 0, count 0, freq 1998, maybe hot ;; prev block 92, next block 94, flags: (NEW, REACHABLE) ;; pred: 92 [100.0%, 180] (FALLTHRU) ;; 96 [100.0%, 1818] (FALLTHRU,DFS_BACK) # ival2_136 = PHI # ival2_140 = PHI _137 = (integer(kind=8)) ival2_136; _138 = _137 + -1; _139 = *xxtrt_25(D)[_138]; _141 = (integer(kind=8)) ival2_140; _142 = _141 + -1; _143 = *xxtrt_25(D)[_142]; if (_139 < _143) goto ; else goto ; 1818 that should be still hot. Or isn't the heuristic backwards? I.e. I would expect the partial anticipance to sit on edge 92->28 (with freq 180) where we need to insert the computation to get the other path hot. Honza