From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2159 invoked by alias); 29 Apr 2009 18:12:06 -0000 Received: (qmail 2097 invoked by uid 22791); 29 Apr 2009 18:12:00 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: sourceware.org Received: from c60.cesmail.net (HELO c60.cesmail.net) (216.154.195.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 29 Apr 2009 18:11:53 +0000 Received: from unknown (HELO epsilon2) ([192.168.1.60]) by c60.cesmail.net with ESMTP; 29 Apr 2009 14:11:52 -0400 Received: from 5ac91543.bb.sky.com (5ac91543.bb.sky.com [90.201.21.67]) by webmail.spamcop.net (Horde MIME library) with HTTP; Wed, 29 Apr 2009 14:11:51 -0400 Message-ID: <20090429141151.f274nwyfb40k0oww-nzlynne@webmail.spamcop.net> Date: Wed, 29 Apr 2009 21:34:00 -0000 From: Joern Rennecke To: Ian Lance Taylor Cc: gcc@gcc.gnu.org Subject: Re: gcc-in-cxx update / multi-targeted gcc References: <20090429064704.r7nzgfg18okko8s8-nzlynne@webmail.spamcop.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) 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: 2009-04/txt/msg00791.txt.bz2 Quoting Ian Lance Taylor : > I'm not sure why you are singling me out. You seemed to be actively working on the branch, and the c++ enum type checks provide a motivation to make changes. Also, this issue should be considered in general when people change their coding habits in order for the code to be c++ ready. > If we decide that a > multi-targeted gcc is a goal we want to support, it's certainly fine > with me to change those enums to int and add casts where appropriate. OK. This is also the route I have followed so far. > (I'm not personally convinced that a multi-targeted gcc is particularly > useful, though I don't object if there is a general desire to support > it.) As the number of cores integrated into each computing device increases, I think it is only natural that we'll see the emergence of specialized cores. E.g. we already see low power cores for base load/standby, superscalar out-of-order cores for sequential processing, and massively parallel architectures for media processing. Having a single compiler that can generate code for all target architectures in a computing device allows to shift (parts of) functions from one architecture to the other depending the nature of the processing task. This also increases the leverage for profile-based feedback and machine learning. > It is perhaps worth noting that the natural way to handle the target > vector in C++ is to make a Target class with a set of virtual methods. Yes, but unfortunately that requires ferrying around the this pointer. If we had virtual static member functions, that would be different. And you'd still have to decide on one function signature for each virtual function - having one target return a pointer to an 8 bit enum and another one return a pointer to a 16 bit enum by the same name just won't do. > Then methods like eh_return_filter_mode would use a covariant return > type in specific implementations. Where the mode is a parameter it > would still have to be changed to int. The signature of these virtual functions would have to be defined with a type that is wide enough to fit all target's enums. And you couldn't fix a hook like ira_cover_classes this way. The caller has to know how wide each element is in the of the array the pointer to the first element of which is being returned. > I think you need to take a step back. What is a natural way to > represent a register class in the machine independent code when writing > in C++? I don't think it is to use an enum type. Having all register classes in one enum gives you some things that you don't get with an compiler implementation language class for each register class. E.g. you can easily iterate over all register classes, and have bitmasks which act as sets of register classes. You can use them as indices in lookup tables. > A register class is > basically an object which implements methods like > bool is_regno_in_class(unsigned int); > HARD_REG_SET registers_in_class(); > bool equals(Reg_class); > bool is_superset_of(Reg_class); > bool is_subset_of(Reg_classS); > Obviously that is a long way off in gcc. Indeed. Expressing this as an actual C++ class would be incompatible with the current goal to be able to build GCC with a C compiler. >> Another enum problem is enum attr_cpu / enum processor_type in the >> sh machine description. We need a variable (sh_cpu aka sh_cpu_attr) >> with this type to be visible inside the attributes generated by genattrt= ab. >> Choices to solve these kind of problems would be: >> - introduce another target header which is guaranteed to be included only >> after enum definitions from generator files are in effect. >> - allow the gcc extension of statement expressions to be used in >> target descriptions, so that a macro could provide an extern declarati= on >> of a variable before using its value. > > A simple approach would be to have a way to say that the enum values for > an attribute were already declared. Then instead of listing the values > in the define_attr, we would just have a standard mapping from constants > of the attribute to the enum names to use. We would have less error > checking in the generator programs, but the errors would be caught when > the generated code was compiled. I don't see how this would work. Remember, genattrtab needs to know about every value in the enumeration so that it can perform its optimizations. I also don't see how your proposal is simpler than adding another header file. FWIW, the current approach of using two enums in parallel works (awkward as it is) also for C++. It just needed adjustments because the two sets of enum constants are no longer interchangable, and a cast is now required when going from one enum to the other.