From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9145 invoked by alias); 14 Nov 2013 22:32:50 -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 9118 invoked by uid 89); 14 Nov 2013 22:32:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.8 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; Thu, 14 Nov 2013 22:32:42 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rAEMWYik002581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Nov 2013 17:32:34 -0500 Received: from stumpy.slc.redhat.com (ovpn-113-161.phx2.redhat.com [10.3.113.161]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id rAEMWXDv002878; Thu, 14 Nov 2013 17:32:34 -0500 Message-ID: <52854F81.6060705@redhat.com> Date: Fri, 15 Nov 2013 02:49: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> <5284781F.3000604@redhat.com> <1384451362.15325.118.camel@surprise> In-Reply-To: <1384451362.15325.118.camel@surprise> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg01705.txt.bz2 On 11/14/13 10:49, David Malcolm wrote: > > FWIW, I prefer the downcasts to adding virtual functions; what I've > tried to do is create a very direct mapping from the status quo, > introducing inheritance to gain the benefits listed earlier in the > thread, whilst only changing "surface syntax". I understand (and I probably encouraged you to stay close as close to the status quo as possible while still moving this stuff forward ;-) > > It seems to me that we're considering the general problem of type-safe > code dispatch: given a type hierarchy, and various sites that want to > vary behavior based on what types they see, how best to invoke the > appropriate code, ensuring that the code that's called "knows" that its > dealing with the appropriate subclass i.e. in a typesafe manner. Right. Certainly in my quick browsing, this is primarily a dispatch problem. I think Andrew had one in his Cauldron slide deck as well. > > There are various idioms for doing this kind of dispatch in C++, a > non-exhaustive list is: > > (a) switches and if/then tests on the GIMPLE_CODE (stmt) - the status > quo, Right. And probably appropriate for now. But I do want us to think about better ways to handle this. > > (b) adding virtual functions to gimple would be another way to handle > type-safe dispatch, but they carry costs: > (i) they would implicitly add a vtable ptr to the top of every > gimple statement, increasing the memory consumption of the process Thats my biggest concern. > (ii) it's my belief that a virtual function call is more expensive > than the kinds of switch/if+then branching that we're currently doing on > the code - though I don't have measurements to back this up The virtual call is probably more expensive, but probably not as much as you might think as the switch likely compiles down to a multi-way branch which is on-par with an indirect call. > > (c) the "Visitor" design pattern [1] - rather than adding virtual > functions to gimple, instead add them to a visitor class e.g.: Basically this just puts the vtable in a different class. But doesn't the wrapping visitor need to know about the underlying details of the gimple statement class? If we're trying to encapsulate things better, doesn't a visitor break the encapsulation? > > (the above isn't *exactly* the Visitor pattern from the Gang of Four > book, I'm doing things in the visitor in order avoiding adding vfuncs to > gimple). Right. My mental model when I wrote my last message as a visit method which dispatched to the statement specific bits, but with the method as a part of the gimple base class. > > This approach avoids adding an implicit vtable field to the top of > gimple [(i) above], and keeps the vtables with the code using them > [(iii) above]. Right. > > However it still would mean (ii) changing from switch/if-then control > flow to vfunc calls, with unknown impact on performance. I'd be nervous > about adding virtual functions anywhere where we're not already jumping > though function ptrs. As noted above, jumping through a function pointer probably isn't much different performance-wise than a multi-way branch. Anyway, just wanted to get the conversation around this started as cleaning this stuff up is a natural follow-on at some point. > > (nods). Note that I don't regard the downcasting as inherently bad, > just one approach to the generic issue of typesafe dynamic code > dispatch. Yes, in many OO textbooks, it's regarded as a code smell, > but then again "goto" has its uses :) Again, my opinions come from working on large codes which did a lot of downcasting (and sadly upcasting too) and it was a major PITA to get sorted out. Thanks, jeff