From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25086 invoked by alias); 10 Aug 2007 16:33:14 -0000 Received: (qmail 25042 invoked by uid 22791); 10 Aug 2007 16:33:13 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 10 Aug 2007 16:33:08 +0000 Received: from zps35.corp.google.com (zps35.corp.google.com [172.25.146.35]) by smtp-out.google.com with ESMTP id l7AGTGIg023433; Fri, 10 Aug 2007 17:29:19 +0100 Received: from localhost.localdomain.google.com (dhcp-172-18-116-220.corp.google.com [172.18.116.220]) (authenticated bits=0) by zps35.corp.google.com with ESMTP id l7AGSwEn031388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Aug 2007 09:28:59 -0700 To: sje@cup.hp.com Cc: gcc-patches@gcc.gnu.org, andreasmeier80@gmx.de Subject: Re: Patch for PR tree-optimization/32941, bootstrap comparision failure References: <200708101549.IAA02582@hpsje.cup.hp.com> From: Ian Lance Taylor Date: Fri, 10 Aug 2007 16:33:00 -0000 In-Reply-To: <200708101549.IAA02582@hpsje.cup.hp.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2007-08/txt/msg00679.txt.bz2 Steve Ellcey writes: > This patch fixes PR tree-optimization/32941, a bootstrap comparision > failure. Currently we sort the goto_queue in tree-eh.c using qsort and > search it with bsearch. Because qsort is an unstable sort and we are > sorting on addresses we can get different orderings during different > bootstrap passes, resulting in the comparision failure. > > This patch removes the sort and replaces the bsearch call with a simple > linear search. The obvious concern with this is compile time > performance but during a bootstrap the largest size goto_queue I saw was > 7 elements and while compiling the C++ SPEC2006 benchmarks, the largest > size I saw was 30. > > Given these relatively small sizes for the goto_queue, I think using a > linear search will not result in any compile time change or may actually > be faster since 99% of the time we search the queue the size is 1. I don't think this is a good idea. I think it will significantly hurt compiler time performance on some machine generated C++ code. I think the idea of not sorting the queue makes sense. I just think we need to augment your patch by adding a pointer_map which maps from statements to queue elements. That is, maybe_record_in_goto_queue will call pointer_map_insert with STMT, and find_goto_replacement will call pointer_map_contains. Ian