From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23133 invoked by alias); 27 Jun 2009 00:55:41 -0000 Received: (qmail 23125 invoked by uid 22791); 27 Jun 2009 00:55:40 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 27 Jun 2009 00:55:32 +0000 Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id n5R0tUAR032296 for ; Fri, 26 Jun 2009 17:55:30 -0700 Received: from rv-out-0708.google.com (rvbf25.prod.google.com [10.140.82.25]) by zps37.corp.google.com with ESMTP id n5R0tRG2027115 for ; Fri, 26 Jun 2009 17:55:28 -0700 Received: by rv-out-0708.google.com with SMTP id f25so15749rvb.28 for ; Fri, 26 Jun 2009 17:55:27 -0700 (PDT) Received: by 10.140.187.10 with SMTP id k10mr907395rvf.13.1246064127522; Fri, 26 Jun 2009 17:55:27 -0700 (PDT) Received: from localhost.localdomain.google.com ([67.218.106.187]) by mx.google.com with ESMTPS id b39sm7214346rvf.8.2009.06.26.17.55.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 26 Jun 2009 17:55:27 -0700 (PDT) To: Matt Cc: gcc@gcc.gnu.org Subject: Re: Phase 1 of gcc-in-cxx now complete References: From: Ian Lance Taylor Date: Sat, 27 Jun 2009 09:48:00 -0000 In-Reply-To: (matt@use.net's message of "Fri\, 26 Jun 2009 16\:50\:23 -0700 \(PDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-System-Of-Record: true 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: 2009-06/txt/msg00631.txt.bz2 Matt writes: >> * Develop some trial patches which require C++, e.g., convert VEC to >> std::vector. > > Do you have any ideas for the easiest starting points? Is there > anywhere that is decently self-contained, or will if have to be a big > bang? Thanks for your interest. I think the one I mentioned--converting VEC to std::vector--is a good starting point. This is the interface in vec.h. Another easy starting point would be converting uses of htab_t to type safe C++ hash tables, e.g., std::tr1:;unordered_map. Here portability suggests the ability to switch to different hash table implementations; see gold/gold.h in the GNU binutils for one way to approach that. Another easy starting point is finding calls to qsort and converting them to std::sort, which typically leads to code which is larger but runs faster. Longer term, we know that memory usage is an issue in gcc. In the old obstack days, we had a range of obstacks with different lifespans, so we could create RTL with a temporary lifetime which was given a longer lifetime when needed. We got away from that because we spent far too much time chasing bugs in which RTL should have been saved to a longer lifetime but wasn't. However, that model should permit us to run with significantly less memory, which would translate to less compile time. I think we might be able to do it by implementing a custom allocator, such as a pool allocator which permits allocating different sizes of memory, and never frees memory. Then the tree class could take an allocator as a template parameter. Then we would provide convertors which copied the tree class to a different allocation style. Then, for example, fold-const.c could use a temporary pool which lived only for the length of the call to fold. If it returned a new value, the convertor would force a copy out of the temporary pool. If this works out, we can use type safety to enforce memory discipline, use significantly less memory during compilation, and take a big step toward getting rid of the garbage collector. Ian