From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9138 invoked by alias); 14 Nov 2013 07:13:47 -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 9124 invoked by uid 89); 14 Nov 2013 07:13:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,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; Thu, 14 Nov 2013 07:13:45 +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 rAE7DalE009164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Nov 2013 02:13:37 -0500 Received: from stumpy.slc.redhat.com (ovpn-113-161.phx2.redhat.com [10.3.113.161]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rAE7DZGf018559; Thu, 14 Nov 2013 02:13:35 -0500 Message-ID: <5284781F.3000604@redhat.com> Date: Thu, 14 Nov 2013 08:38: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: David Malcolm CC: Michael Matz , Andrew MacLeod , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Add gimple subclasses for every gimple code (was Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)) References: <5271CBF9.2070005@redhat.com> <1383236801-13234-1-git-send-email-dmalcolm@redhat.com> <52741EE2.3030100@redhat.com> <1383671947.5282.93.camel@surprise> <1383800204.31927.33.camel@surprise> <527B25ED.9030804@redhat.com> <1383937364.31927.66.camel@surprise> In-Reply-To: <1383937364.31927.66.camel@surprise> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg01556.txt.bz2 On 11/08/13 12:02, David Malcolm wrote: >> I wouldn't mind seeing a small example proof of concept posted to help >> those who don't see where this is going understand the goal. I would >> recommend against posting another large patch for inclusion at this time. > Attached is a proof-of-concept patch which uses the > gimple_statement_switch subclass (as a "gimple_switch" typedef). This > is one of the subclasses that the earlier patch added, which has no new > fields, but which carries the invariant that, if non-NULL, > gimple_code (gs) == GIMPLE_SWITCH. [ ... ] Thanks. It's pretty much what I expected. Obviously for other codes there may be a lot more changes that you have to slog through, but I think this example shows the main concepts. Presumably in this new world order, the various gimple statement types will continue to inherit from a base class. That seems somewhat inevitable and implies a certain amount of downcasting (via whatever means we agree upon). The worry, in my mind is how pervasive the downcasting will be and how much of it we can get rid of over time. I may be wrong, but ISTM some of the downcasting is a result of not providing certain capabilities via (pure?) virtual methods. For example, expand_gimple_stmt_1 seems ripe for implementing as virtual methods. ISTM you could also have virtuals to build the statements, dump/pretty-print them, verify them, branch/edge redirection, estimations for inlining, etc. ISTM that would eliminate a good chunk of the downcasting. Just to be clear, I'm not asking you to make those changes, just for your thoughts on approaches to eliminate the downcasting based on what we've seen so far. Thanks for pulling this together to help illustrate how some of this might look in practice. I hope others take the time to look closely as this example and think about what it means in terms of how we would be writing code 6 months from now. Jeff