From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12315 invoked by alias); 15 Nov 2012 14:48:39 -0000 Received: (qmail 12305 invoked by uid 22791); 15 Nov 2012 14:48:37 -0000 X-SWARE-Spam-Status: No, hits=-6.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,TW_TM X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Nov 2012 14:48:31 +0000 Received: from relay1.suse.de (unknown [195.135.220.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 182C8A39D1; Thu, 15 Nov 2012 15:48:30 +0100 (CET) Date: Thu, 15 Nov 2012 14:48:00 -0000 From: Michael Matz To: Lawrence Crowl Cc: "gcc@gcc.gnu.org" Subject: Re: Simplifying Gimple Generation In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2012-11/txt/msg00230.txt.bz2 Hi Lawrence, On Wed, 14 Nov 2012, Lawrence Crowl wrote: > Diego and I seek your comments on the following (loose) proposal. In principle I agree with the goal, I'm not sure I like the specific way yet, and even if I do I have some suggestions: > We will add a set of helper classes to be used as local variables > to manage the details of handling the existing types. I think one goal should be to minimize the number of those helper classes if we can. And use clear names, for the statement builder e.g. stmt_builder, or the like, not just ssa_seq. > We propose a simplified form using new build helper classes ssa_seq > and ssa_stmt that would allow the above code to be written as > follows. > > ssa_seq q; > ssa_stmt t = q.stmt (NE_EXPR, shadow, 0); > ssa_stmt a = q.stmt (BIT_AND_EXPR, base_addr, 7); > ssa_stmt b = q.stmt (shadow_type, a); I think consistency should trump brevity here, so also add a tree code for the converter, i.e. ssa_stmt b = q.stmt (NOP_EXPR, shadow_type, a); The method name should imply the action, e.g. 'add_stmt' or append_stmt or the like. I'm not sure if we need the ssa_stmt class. We could use overloading to accept 'gimple' as operands, with the understanding that those will be implicitely converted to 'tree' by accessing the LHS: gimple append_stmt (gimple g, tree_code code, gimple op1, tree op2) { return append_stmt (g, code, gimple_lhs (op1), op2); } (where gimple_lhs would ICE when the stmt in question doesn't have one). As gimple statements are their own iterators meanwhile I'm not even sure if you need the ssa_seq (or ssa_stmt_builder) class. The above append_stmt would simply add the newly created statement to after 'g'. That is, I'm not yet convinced that you really need any local data for which you'd have to add helper classes. So, you solve multiple problems (and I agree that they are problems), and these are: > There are a few important things to note about this example. > > .. We have a new class (ssa_seq) that knows how to sequence > statements automatically and can build expressions out of types. 1) automatic sequencing; I think we don't need a helper class for that, just new helper functions. > .. Every statement created produces an SSA name. Referencing an > ssa_stmt instance in a an argument to ssa_seq::stmt retrieves the > SSA name generated by that statement. 2) gimple with LHS and their LHS are isomorphic; I think overloads will solve this as well without a wrapper class. > > .. The statement result type is that of the arguments. 3) easy stmt building 3a) type inference; I agree with all your rules > .. The type of integral constant arguments is that of the other > argument. (Which implies that only one argument can be constant.) > > .. The 'stmt' method handles linking the statement into the sequence. See 1) > .. The 'set_location' method iterates over all statements. So it iterates from the starting point of the ssa_seq to its end (presumably only overriding locations that don't yet have one). This can also be implemented by remembering the starting point of the gimple sequence (I'd remember a gimple stmt, you have to remember the ssa_seq object, so it's the same there). All in all I think we can severely improve on building gimple statements without introduction of any helper class. Basically, whenever a helper class merely contains one member of a different type, then I think that other type should be improved so that the wrapper class isn't necessary anymore. Fewer types -> good :) > Generating a Type Apart from naming of some methods to imply the action done, I don't have any opinion about this at this point. Though I agree that again the boilerplate sequencing (_CONTEXT and _CHAIN) should be improved. Ciao, Michael.