From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15903 invoked by alias); 15 Aug 2014 13:26:22 -0000 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 Received: (qmail 15861 invoked by uid 89); 15 Aug 2014 13:26:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 15 Aug 2014 13:26:20 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7FDQFek018701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 15 Aug 2014 09:26:15 -0400 Received: from stumpy.slc.redhat.com (ovpn-113-24.phx2.redhat.com [10.3.113.24]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7FDQDO2032632; Fri, 15 Aug 2014 09:26:13 -0400 Message-ID: <53EE0A74.1080909@redhat.com> Date: Fri, 15 Aug 2014 13:26:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Richard Biener , Sebastian Pop CC: Steve Ellcey , David Malcolm , GCC Patches , james.greenhalgh@arm.com, Jakub Jelinek Subject: Re: RFC: Patch for switch elimination (PR 54742) References: <47b32a49-298e-44f0-b84b-b8f664847a67@email.android.com> <53EA7BD0.1030901@redhat.com> <1407883486.2601.86.camel@ubuntu-sellcey> <20140813205519.GB23343@instance-1.c.bardezibar.internal> <53EBD365.4040100@redhat.com> <53ECDC13.8090808@redhat.com> <1408032769.28418.183.camel@surprise> <53ECE1F9.8050909@redhat.com> <1408040733.2601.134.camel@ubuntu-sellcey> <20140814184504.GA27995@instance-1.c.bardezibar.internal> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg01585.txt.bz2 On 08/15/14 04:07, Richard Biener wrote: > On Thu, Aug 14, 2014 at 8:45 PM, Sebastian Pop wrote: >> Steve Ellcey wrote: >>> I understand the desire not to add optimizations just for benchmarks but >>> we do know other compilers have added this optimization for coremark >>> (See >>> http://community.arm.com/groups/embedded/blog/2013/02/21/coremark-and-compiler-performance) >>> and the 13 people on the CC list for this bug certainly shows interest in >>> having it even if it is just for a benchmark. Does 'competing against other >>> compilers' sound better then 'optimizing for a benchmark'? >> >> I definitely would like to see GCC trunk do this transform. What about we >> integrate the new pass, and then when jump-threading manages to catch the >> coremark loop, we remove the pass? > > It never worked that way. > > A new pass takes compile-time, if we disable it by default it won't help > coremark (and it will bitrot quickly). > > So - please fix DOM instead. Steve's work is highly likely to be faster than further extending the threading code -- that's one of the primary reasons I suggested Steve resurrect his work. Jeff