From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32472 invoked by alias); 5 Apr 2011 10:14:25 -0000 Received: (qmail 32458 invoked by uid 22791); 5 Apr 2011 10:14:24 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-wy0-f175.google.com (HELO mail-wy0-f175.google.com) (74.125.82.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 05 Apr 2011 10:13:50 +0000 Received: by wye20 with SMTP id 20so194787wye.20 for ; Tue, 05 Apr 2011 03:13:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.150.207 with SMTP id z15mr8225244wbv.149.1301998429281; Tue, 05 Apr 2011 03:13:49 -0700 (PDT) Received: by 10.227.0.140 with HTTP; Tue, 5 Apr 2011 03:13:49 -0700 (PDT) In-Reply-To: <20110404192512.GD23480@codesourcery.com> References: <20110404184952.GA5423@nightcrawler> <20110404192512.GD23480@codesourcery.com> Date: Tue, 05 Apr 2011 10:14:00 -0000 Message-ID: Subject: Re: [PATCH] allocate combine.c:LOG_LINKS in an alloc_pool From: Richard Guenther To: Nathan Froyd Cc: Steven Bosscher , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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 X-SW-Source: 2011-04/txt/msg00305.txt.bz2 On Mon, Apr 4, 2011 at 9:25 PM, Nathan Froyd wro= te: > On Mon, Apr 04, 2011 at 09:01:20PM +0200, Steven Bosscher wrote: >> On Mon, Apr 4, 2011 at 8:49 PM, Nathan Froyd = wrote: >> > This patch does just what $SUBJECT suggests. =A0Benefits: >> > >> > - Smaller data structures in combine; >> > - Freeing LOG_LINKS becomes much easier (don't have to transfer >> > =A0everything to the INSN_LIST free list); >> > >> > Potential downsides: >> > >> > - Less sharing of INSN_LIST nodes might mean more cache thrashing. >> >> It looks like LOG_LINKs are allocated once. An alloc pool is >> interesting if you allocate and free objects of the same size all the >> time. In this case, I'd say an obstack would be a simpler and better >> choice. > > FWIW, I went with alloc_pool because of the stats-for-free you get with > appropriate configury. I agree with Steven - alloc-pools have higher overhead because they deal with memory re-use which you don't appearantly need. Richard.