From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9112 invoked by alias); 24 Nov 2015 14:58: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 9083 invoked by uid 89); 24 Nov 2015 14:58:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: fencepost.gnu.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (208.118.235.10) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 24 Nov 2015 14:58:10 +0000 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59227) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1a1F2l-0007dH-Lv for gcc-patches@gnu.org; Tue, 24 Nov 2015 09:58:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1F2g-0003RN-2Y for gcc-patches@gnu.org; Tue, 24 Nov 2015 09:58:07 -0500 Received: from relay1.mentorg.com ([192.94.38.131]:44398) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1F2f-0003RI-U0 for gcc-patches@gnu.org; Tue, 24 Nov 2015 09:58:02 -0500 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1a1F2d-0003NH-Se from Tom_deVries@mentor.com ; Tue, 24 Nov 2015 06:58:00 -0800 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.224.2; Tue, 24 Nov 2015 14:57:58 +0000 Subject: Re: [PATCH, 10/16] Add pass_oacc_kernels pass group in passes.def To: Richard Biener References: <5640BD31.2060602@mentor.com> <5640FB07.6010008@mentor.com> <5649C41A.40403@mentor.com> <564DA4CA.3020506@mentor.com> <564F1F85.1000108@mentor.com> <564F4B72.8010605@mentor.com> <565455C9.7000206@mentor.com> <56546E0A.3060704@mentor.com> CC: "gcc-patches@gnu.org" , Jakub Jelinek From: Tom de Vries Message-ID: <56547AC5.6050903@mentor.com> Date: Tue, 24 Nov 2015 15:05:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Windows NT kernel [generic] [fuzzy] X-Received-From: 192.94.38.131 X-SW-Source: 2015-11/txt/msg02918.txt.bz2 On 24/11/15 15:33, Richard Biener wrote: > On Tue, 24 Nov 2015, Tom de Vries wrote: > >> On 24/11/15 14:13, Richard Biener wrote: >>> On Tue, 24 Nov 2015, Tom de Vries wrote: >>> >>>>> On 23/11/15 11:02, Richard Biener wrote: >>>>>>> On Fri, 20 Nov 2015, Tom de Vries wrote: >>>>>>> >>>>>>>>> On 20/11/15 14:29, Richard Biener wrote: >>>>>>>>>>> I agree it's somewhat of an odd behavior but all passes >>>>>>> should >>>>>>>>>>> either be placed in a sub-pipeline with an outer >>>>>>>>>>> loop_optimizer_init()/finalize () call or call both >>>>>>> themselves. >>>>>>>>> >>>>>>>>> Hmm, but adding loop_optimizer_finalize at the end of pass_lim >>>>>> breaks the >>>>>>>>> loop >>>>>>>>> pipeline. >>>>>>>>> >>>>>>>>> We could use the style used in pass_slp_vectorize::execute: >>>>>>>>> ... >>>>>>>>> pass_slp_vectorize::execute (function *fun) >>>>>>>>> { >>>>>>>>> basic_block bb; >>>>>>>>> >>>>>>>>> bool in_loop_pipeline = scev_initialized_p (); >>>>>>>>> if (!in_loop_pipeline) >>>>>>>>> { >>>>>>>>> loop_optimizer_init (LOOPS_NORMAL); >>>>>>>>> scev_initialize (); >>>>>>>>> } >>>>>>>>> >>>>>>>>> ... >>>>>>>>> >>>>>>>>> if (!in_loop_pipeline) >>>>>>>>> { >>>>>>>>> scev_finalize (); >>>>>>>>> loop_optimizer_finalize (); >>>>>>>>> } >>>>>>>>> ... >>>>>>>>> >>>>>>>>> Although that doesn't strike me as particularly clean. >>>>>>> >>>>>>> At least it would be a consistent "unclean" style. So yes, the >>>>>>> above would work for me. >>>>>>> >>>>> >>>>> Reposting using the in_loop_pipeline style in pass_lim. >>> The tree-ssa-loop-im.c changes are ok >> >> OK, I'll commit those. >> >>> (I suppose the other changes >>> are in the other patch you posted as well). >> >> This ( https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02882.html ) patch >> contains changes related to adding pass_oacc_kernels2. Are those the "other >> changes" you're referring to? > > No, the other pathc adding oacc_kernels pass group to passes.def. > I don't understand. There 's only one patch adding oacc_kernels pass group to passes.def (which is the one in this thread). > Btw, at some point splitting patches too much becomes very much > confusing instead of helping. Would it help if I merge "Add pass_oacc_kernels" with this patch? Thanks, - Tom