From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5091 invoked by alias); 7 Nov 2013 14:42:32 -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 5081 invoked by uid 89); 7 Nov 2013 14:42:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.1 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPAM_SUBJECT,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, 07 Nov 2013 14:42:29 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rA7EgLQa021798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Nov 2013 09:42:21 -0500 Received: from [10.10.54.48] (vpn-54-48.rdu2.redhat.com [10.10.54.48]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rA7EgJvq014428; Thu, 7 Nov 2013 09:42:19 -0500 Message-ID: <527BA6CB.3000605@redhat.com> Date: Thu, 07 Nov 2013 14:53:00 -0000 From: Andrew MacLeod User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: Richard Biener CC: Bernd Schmidt , Jeff Law , David Malcolm , GCC Patches Subject: 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> <527960A8.7030107@redhat.com> <527A21DB.301@codesourcery.com> <527AACE6.3040005@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00775.txt.bz2 On 11/07/2013 05:08 AM, Richard Biener wrote: > >> 2 - I really believe gimple needs a type system different from front end >> trees, that is my primary motivation. I'm tired of jumping through hoops to >> do anything slightly different, and I got fed up with it. With a separate >> type system for gimple, we can rid ourselves of all the stuff that isn't >> related to optimization and codegen... Could we do this with trees? >> possibly, but if I'm going to go to the effort of converting the front end >> tree types into a new or reduced-type subset, I might as well put that >> effort into something that is more appropriate right from the start. > I'm not sure. Especially the idea of wrapping everything in a > I'm-not-a-tree-well-but-I-really-still-am scares the hell out of me. > And I put that into the very same basket of things you now complain about. Well, this first phase is a transitional one... If it were possible, I'd change them all at once to not use a tree... but I don't think that is feasible. There is too much to find and change, and the source base is constantly changing. We can't just freeze the base for a year. so until I can get them all changes, they have to act like trees and interact like trees, so we make them trees under the covers. Short term pain and discomfort... If it helps, during the transition you can view it as replacing trees with oddly named tree subclasses which provide static type checking instead of run time GIMPLE_CHECK() calls :-) >> By replacing those uses with an actual type, we'll get >> static type checking which is another improvement. There is only one way >> to move the middle/back end off of types as trees that I can see. Go >> through the source base and find all the places which use trees as types, >> and replace them with an actual type. This can't be done all at once, its >> too big a job... So I propose a plan which allows a new gimple type and >> current trees to coexist. Once the conversion is complete we can easily >> implement a type system that has the features and traits we want. > Note that on 'gimple' there are no types ... the types are on the objects > 'gimple' refers to and those are 'tree's. So you'd need to change the > 'tree's to have TREE_TYPE not be a 'tree'. Or simply subclass > 'tree' so you can distinguish a tree type from a tree non-type statically > (a bit awkward with the current union setup). > > But maybe I'm confusing what you call 'type'. Im talking about changing the type gimple statements refer to, and also what decls and expressions will refer to... making that the gimple_type. Today, thats a TREE_TYPE tree. During the transition period this gimple_type is indeed a tree under the covers.. so that all the existing code can work even if it hasnt been converted yet. Once everything is converted, then gimple_type has the tree removed from its declaration and we replace it with the bits we need/want... and it will no longer function as a tree.. gimplification will create these from the trees the front end created. >> 4 - I realized that if I am going through the entire code base to find all >> the type locations, its very little extra work to also do the same for decls >> and expressions. Then we'll have static type checking for those as well. >> >> 5 - When done we will be significantly closer to having the ability to >> create a self contained IL that we can strictly define... That alone seems >> a worthwhile goal to me. The IL then becomes appropriate for streaming at >> any point in during compilation. This means any front end or tool can >> easily generate or consume a gimple stream which opens up numerous >> opportunities... That is pretty hard to enable today. > Have fun with dealing with our legacy frontends ;) Or didn't you > actually mean "any point" during compilation? ... oh, you talk about > GIMPLE. So no plans for Frontend ASTs aka GENERIC for our legacy > frontends? I meant any point where we are in gimple... Thats the only point we really care about. Once control is passed to the middle end. No plans to touch GENERIC at all... in fact, GENERIC and 'tree' will become true synonyms when I'm done, because gimple wont have any trees in it anywhere. And rtl will also refer to gimple nodes. It just wont matter what warts are in trees. >> Im going to do the initial bits on a branch for the first couple of months, >> and during that time convert a number of files over to the new gimple >> interface. Then we can look at it, measure it, comment on it, tweak it, >> whatever. You can see exactly what we'll be getting into before we fully >> commit. > Before we fully commit we want to see the underlying object changes. > Because I still doubt this all will work out without seriously restructuring > the entanglement of our tree-based frontends and the middle-end > (say "fold"). > > That is, I still think you are starting this at the wrong end. You first > need to solve the entanglement issue before you can seriously consider > making any real change to the data structures GIMPLE relies on. That is part of the experiment. RIght now I don't know for sure what the real issues will be. I learned a valuable lesson long time ago... measure a problem to determine the cause rather than assume you know where it is. This process will show exactly where there are entanglements are that need to be dealt with. It may be that by the time stage 1 rolls around, I will have identified a few other things that really need to be addressed first. And then I'll then work to address them. Fold is indeed one of them, but that is one of the reasons why there is also a plan in motion (sort of) to reduce the folding in the front end to a bare minimum... and either have its own minimal folder, or provide an interface through gimplification to a gimple folder to do what it needs. This is all in the original document. The operating theory is that front ends can do whatever the do today, and the gimplification process will turn trees into whatever gimple object is needed: expr, decl, type, whatever. Today, gimplification only addresses turning tcc_statement trees into gimple statements. What I am proposing effectively does this for all the rest of the tree class nodes. >> I think it will be an improvement over what we have today and much >> easier to work with. If the consensus is that it bites, then we leave it on >> the branch, and what have we lost? a few months of my time and we've gained >> some really useful knowledge. >> >> And no, if I can get trees out of gimple, I don't intend to ever touch them >> again! :-) > Well, I'm betting that you'll re-invent sth like 'tree' just don't > call it 'tree' ;) > You need to transparently refer to constants, SSA names and decls > (at least) as GIMPLE statement operands. You probably will make > a "gimple statement operand" base class. Well - that's a 'tree' ;) > > Certainly at the beginning when I have to mimic trees there will be a base gimple_operand of some sort which is effectively a 'typed' node... It's required for compatibility. But once trees are no longer required, we are then free to change this. The definition of a gimple_stmt can remove the operand array of 'like objects' (ie trees), and replace it with more context.. One possibility is that gimple_assign could be expanded to have multiple forms of statically typed operands inheriting from the gimple_assign class... ie. decl = const, decl = decl op const (or possibly just decl = gimple_2op_expr or some such thing.. i dont know what gimple_exprs will look like yet) decl = decl mem_expr = const etc. and whatever else is needed. This will help define and enforce a formal definition of the gimple IL... There are other options, but which one to use would be best determined once we have a handle on the other gimple objects and, more importantly, the ability to change their behaviour. Andrew