From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23552 invoked by alias); 5 Nov 2013 17:28: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 23541 invoked by uid 89); 5 Nov 2013 17:28:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.0 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 05 Nov 2013 17:27:59 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rA5HRqGm017879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Nov 2013 12:27:52 -0500 Received: from stumpy.slc.redhat.com (ovpn-113-132.phx2.redhat.com [10.3.113.132]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rA5HRp3i009856; Tue, 5 Nov 2013 12:27:51 -0500 Message-ID: <52792A97.9000507@redhat.com> Date: Tue, 05 Nov 2013 17:52:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Andrew MacLeod , gcc-patches , Richard Biener , Diego Novillo Subject: Re: [patch] Create gimple-expr..[ch] ... was Re: RFC: gimple.[ch] break apart References: <5271CBF9.2070005@redhat.com> <52791C46.6090909@redhat.com> In-Reply-To: <52791C46.6090909@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00441.txt.bz2 On 11/05/13 09:26, Andrew MacLeod wrote: > On 10/30/2013 11:18 PM, Andrew MacLeod wrote: >> >> >> As a result, any gimple queries regarding types, decls, or expressions >> are actually tree queries. They are sprinkled throughout gimple.[ch] and >> gimplify.[ch], not to mention tree.[ch] as well as other parts of the >> compiler where they happened to be needed. This has caused various >> ordering issues among the inline functions when I tried to split out the >> stmt, iterator, and gimplification bits from gimple.[ch]. Not to >> mention a lack of an obvious home for some of these functions. >> >> I'd like to move these as I encounter them into a new file, >> gimple-decl.[ch]. When I'm working on the other gimple classes, this >> will be further split into gimple-decl, gimple-type and gimple-expr as >> appropriate but it seems reasonable to create just the one file now to >> clump them since there is no other formal organization. So any function >> which is actually querying/setting/building a decl, type, or expression >> for gimple would go here. > > I decided to name the new file gimple-expr.[ch] instead of > gimple-decl.... This will eventually split into gimple-type.[ch], > gimple-decl.[ch], and gimple-expr.[ch]. I could split them that way now > if desired, but isn't critical yet. maybe I should just do that... > Anyway, of the 3 files, gimple-expr will depend on the other 2, and thus > is likely to be the one #included in places like the rtl generation > files that need access to all these gimple dictionary/expression > routines. (eventually those rtl files will include only gimple-expr.h > and not tree.h :-). > > In any case, I had to do this split from gimple.h first since > gimple-stmt.[ch] and the others require some of these basic routines, > and I can't split anything else out first without then getting an > include dependency cycle between gimple.h and gimple-stmt.h for > instance. This way gimple-stmt.h can include gimple-expr.h, and then > gimple.h can include gimpe-stmt.h and no chicken/egg situation. > > This contains just the functions that are in either in, or prototyped > in, gimple.h, and is just the first cut. There are more things that > will eventually get put here from gimple.c, but their prototypes are in > places like tree.h and more include cycles or poor requirements on files > to include are exposed if I move them now since front ends or rtl files > are using those routines (like get_base_address). There are also a few > I wanted to hold off on and see how things work out before moving them. > > In any case, I tried to pull out the functions that operated on trees > currently and performed an operation on a type, decl, or expression. My > litmus test was usually, "Is this liekly going to be a method of a type, > decl or expr class relating to the object itself." and moved it if it > seemed so. > > The slightly iffier ones were extract_ops_from_tree*() and > gimple_cond_get_ops_from_tree()... Those clearly worked on expressions > and not statements, but are utilized in places like rtl land that don't > deal with stmts... so they need to be exposed via the expression > processing and interface. Its also quite possible those will end up in > gimplify.[ch] once I get that far... > > I do expect there will still be a little bit of fine tuning, but this is > the first cut to enable me to split out gimple-stmts.[ch] next. > > Bootstraps on x86_64-unknown-linux-gnu with no new regressions. OK? OK. jeff