From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112183 invoked by alias); 21 Mar 2018 15:43:37 -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 112171 invoked by uid 89); 21 Mar 2018 15:43:36 -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,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= 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; Wed, 21 Mar 2018 15:43:35 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 27BF0B033; Wed, 21 Mar 2018 15:43:33 +0000 (UTC) Date: Wed, 21 Mar 2018 15:49:00 -0000 From: Richard Biener To: Tom de Vries cc: GCC Patches Subject: Re: [parloops, PR83126], Use cached affine_ivs canonicalize_loop_ivs In-Reply-To: <4b1d8bca-81b0-16e1-6df9-6bc76fa9d9a7@mentor.com> Message-ID: References: <72456add-0339-35cf-c9d6-6aade4af6050@mentor.com> <4b1d8bca-81b0-16e1-6df9-6bc76fa9d9a7@mentor.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2018-03/txt/msg01106.txt.bz2 On Wed, 21 Mar 2018, Tom de Vries wrote: > On 03/12/2018 01:14 PM, Richard Biener wrote: > > On Thu, 22 Feb 2018, Tom de Vries wrote: > > > > > Hi, > > > > > > this patch fixes an ICE in the parloops pass. > > > > > > The ICE (when compiling the test-case in attached patch) follows from the > > > fact > > > that here in gen_parallel_loop the call to canonicalize_loop_ivs fails to > > > "base all the induction variables in LOOP on a single control one": > > > ... > > > /* Base all the induction variables in LOOP on a single control one.*/ > > > canonicalize_loop_ivs (loop, &nit, true); > > > ... > > > > > > This is caused by the fact that for one of the induction variables, > > > simple_iv > > > no longer returns true (as was the case at the start of > > > gen_parallel_loop). > > > This seems to be triggered by the fact that during loop_version we call > > > scev_reset (although I'm not sure why when recalculating scev info we're > > > not > > > reaching the same conclusion as before). > > I guess the real reason is that canonicalize_loop_ivs calls > > create_iv first which in the parloop case with bump-in-latch true > > and then incrementally re-writes PHIs, eventually wrecking other > > PHIs SCEV. In this case the 2nd PHIs evolution depends on the > > first one but the rewritten ones depend on the new IV already. > > > > So the better fix (maybe not 100% enough) would be to re-organize > > canonicalize_loop_ivs to first do analysis of all PHIs and then > > rewrite them all. > > > > Focusing on the re-organize first, is this sort of what you had in mind? Yes, though not sure why you need to have a hash-map here, just pushing to a vector of PHIs would work, no? Or alternatively a bitmap of SSA versions so you have a way to match the gphi iterator with the set of IVs. But the vector should be sorted in PHI order so just traversing the PHIs looking for the "next" PHI in the vector would work I guess. Does it help with the original issue btw? Richard. > Bootstrapped and reg-tested on x86_64. > > Thanks, > - Tom > -- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)