From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23554 invoked by alias); 20 Oct 2011 14:16:04 -0000 Received: (qmail 23370 invoked by uid 22791); 20 Oct 2011 14:16:02 -0000 X-SWARE-Spam-Status: No, hits=-7.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 20 Oct 2011 14:15:46 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p9KEFiPL000577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Oct 2011 10:15:45 -0400 Received: from [10.36.6.207] (vpn1-6-207.ams2.redhat.com [10.36.6.207]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p9KEFgKP012706; Thu, 20 Oct 2011 10:15:43 -0400 Subject: Re: adding destroyable objects into Ggc From: Torvald Riegel To: Duncan Sands Cc: gcc@gcc.gnu.org In-Reply-To: <4EA013B4.2050506@free.fr> References: <20111018171201.361304028ab94f102f827bd2@starynkevitch.net> <20111018191350.470cd6b1cd291373d5ff3f2c@starynkevitch.net> <20111019135602.GA19325@ours.starynkevitch.net> <20111020115652.GA14705@ours.starynkevitch.net> <4EA013B4.2050506@free.fr> Content-Type: text/plain; charset="UTF-8" Date: Thu, 20 Oct 2011 14:52:00 -0000 Message-ID: <1319120141.5756.651.camel@triegel.csb> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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: 2011-10/txt/msg00352.txt.bz2 On Thu, 2011-10-20 at 14:27 +0200, Duncan Sands wrote: > And that's it. The price you pay for this simplicity is the need to keep track > of uses - and this does cost compilation time (clear to anyone who does some > profiling of LLVM) but it isn't that big. The big advantage is that memory > management is easy - so easy that I suspect many LLVM users never thought > about the design choices (and trade-offs) that make it possible. Having the def-use links always available is amore a feature than a disadvantage IMO, together with the (implicit) coding style that comes along with it. Especially for LLVM beginners, navigating through instructions and changing them is very simple. It provides people with an easy way to learn about LLVM because one just has to remember the def-use and contained-in relationships (module - function/globals - instruction(/argument)), and then one can learn about new kinds of instructions etc. on demand when one actually needs to. But the basic means of navigating are the same (and mostly the same function names etc. IIRC), irrespective of whether one is going from a module to a function or from a function to an instruction. Torvald