From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111362 invoked by alias); 22 Oct 2015 13:12:01 -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 111189 invoked by uid 89); 22 Oct 2015 13:11:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 22 Oct 2015 13:11:54 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 624BB8C1AB; Thu, 22 Oct 2015 13:11:53 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-53.ams2.redhat.com [10.36.116.53]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9MDBpI2022465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 22 Oct 2015 09:11:52 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id t9MDBmIK021697; Thu, 22 Oct 2015 15:11:49 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id t9MDBk1e021696; Thu, 22 Oct 2015 15:11:46 +0200 Date: Thu, 22 Oct 2015 13:15:00 -0000 From: Jakub Jelinek To: Tom de Vries Cc: Richard Biener , Thomas Schwinge , Jan Hubicka , "gcc-patches@gcc.gnu.org" , Julian Brown Subject: Re: Don't dump low gimple functions in gimple dump Message-ID: <20151022131146.GQ478@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <87k3bnecq3.fsf@schwinge.name> <537B0F6D.7060808@mentor.com> <87617mndrv.fsf@kepler.schwinge.homeip.net> <55706892.8050701@mentor.com> <20151022122717.GO478@tucnak.redhat.com> <5628DBD6.3040204@mentor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5628DBD6.3040204@mentor.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg02247.txt.bz2 On Thu, Oct 22, 2015 at 02:51:34PM +0200, Tom de Vries wrote: > On 22/10/15 14:27, Jakub Jelinek wrote: > >The state before the patch is: > >1) the omp_fn children created during the pre-SSA ompexp pass are dumped > > first in the *.ssa dump and in all the following ones (these are created > > as low gimple, non-SSA) > > Hi, > > I do see those child fns before the ssa dump, in the fixup_cfg1 dump (and > with -fipa-tree-all, also in the visibility dump, just after the ompexp > dump). Oh, indeed. Any case, I think, with the patch 1) behaves the most desirable way now, no dumps before ompexp show it, and ompexp dump shows both the new child functions and original function with the outlined code already removed. And all dumps after ompexp show both as well. > [ Not that I disagree with dumping the child fn in ompexp dump. ] > > >2) the omp_cpyfn children created during the pre-SSA ompexp pass are dumped > > first in the *.omplower dump and in all the following ones (these are > > created as high gimple) And this is probably fine too, as the cpyfn functions are artificially created, they don't contain code that has been moved from somewhere else. > >3) the omp_fn children created during the parloops/ompexpssa passes > > are dumped first post-IPA (or during IPA?) and in all the following ones > > (these are created as SSA gimple) Bet what you'd want most would be to be able to create new functions and mark them not just as SSA low gimple, but also be able to say, skip everything in the pass pipeline for these functions until pass this and this, i.e. start pass pipeline with pass->next of the creating pass. Then it would neither show up in the earlier dumps, nor be processed multiple times by the same passes. We'd need the && !gimple_in_ssa_p I've added in the patch removed once that is done... Jakub