From patchwork Thu Jun 25 15:08:12 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Makarov X-Patchwork-Id: 488478 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id F3FB71402C3 for ; Fri, 26 Jun 2015 01:08:33 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=lzmcf8uS; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; q=dns; s= default; b=v+CChFIpbnF2/6n8RgffHtfGgfjGl64jcuQJMn5KUgUM25+tQweNq H2SchToubekogqY4+Qkiy8tlgtAWoVyOKOeL2FPADJCO8K68QYySw56fZi/cL4pj yYQgh6AeAyC4TZoxLHuaSS2/3StBlSAdKgYTWPyEhIddyKvj3SWQ5U= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s=default; bh=OPkAMdRYmyUvqgBG9zfo1BjLbm4=; b=lzmcf8uSkhVO1K1Abep0ZXhmhxWu eRyOHWVG8XtFi0s01a3kFsrgoiHBFcAab8gX595CIfEa0usU/wXMDU77znMwNGme 5fjhTJlBeDk++f006yAEt9VufH6RyLZ6hMJte4TNpciNB5sfkRya66bE2mmw6FT2 xSbJYC5yxXCTS1w= Received: (qmail 92288 invoked by alias); 25 Jun 2015 15:08:25 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 92278 invoked by uid 89); 25 Jun 2015 15:08:25 -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_50, KAM_ASCII_DIVIDERS, KAM_LAZY_DOMAIN_SECURITY, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=no 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; Thu, 25 Jun 2015 15:08:15 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id EB0433708EA; Thu, 25 Jun 2015 15:08:13 +0000 (UTC) Received: from topor.usersys.redhat.com (unused-10-15-17-214.yyz.redhat.com [10.15.17.214]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5PF8D8M021238; Thu, 25 Jun 2015 11:08:13 -0400 Message-ID: <558C195C.3010606@redhat.com> Date: Thu, 25 Jun 2015 11:08:12 -0400 From: Vladimir Makarov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Zhouyi Zhou , gcc-patches@gcc.gnu.org Subject: Re: [PATCH IRA] save a bitmap check References: In-Reply-To: X-IsSubscribed: yes On 06/24/2015 05:54 AM, Zhouyi Zhou wrote: > In function assign_hard_reg, checking the bit of conflict_a in > consideration_allocno_bitmap is unneccesary, because when retry_p is > false, conflicting objects are always inside of the same loop_node > (this is ensured in function process_bb_node_lives which marks the > living objects to death near the end of that function). > > > > Thanks for reporting this. I believe you are right the bitmap check is not necessary. When I wrote the code I keep in my mind other possibilities which were not implemented and I don't see the code will be necessary for foreseeable future. Of course the effect on compilation time is tiny (it is about 0.05% reported by valgrind lackey on compilation of combine.c with -O2). Still it is a bit uncomfortable for me that my code wastes unnecessary computer cycles. So I modified a bit your code taking Jeff's proposals into account and committed it into trunk. The patch was bootstrapped on x86-64. Committed as rev. 224944. Your email reminded me that I need to commit another your patch which I promised to commit when GCC is on stage1. I am going to do it today. Index: ChangeLog =================================================================== --- ChangeLog (revision 224943) +++ ChangeLog (working copy) @@ -1,3 +1,9 @@ +2015-06-25 Zhouyi Zhou + Vladimir Makarov + + * ira-color.c (assign_hard_reg): Remove unecessary bitmap check. + Add assert. + 2015-06-25 Richard Biener * fold-const.c (fold_binary_loc): Move simplification of Index: ira-color.c =================================================================== --- ira-color.c (revision 224943) +++ ira-color.c (working copy) @@ -1733,15 +1733,22 @@ assign_hard_reg (ira_allocno_t a, bool r /* Reload can give another class so we need to check all allocnos. */ if (!retry_p - && (!bitmap_bit_p (consideration_allocno_bitmap, - ALLOCNO_NUM (conflict_a)) - || ((!ALLOCNO_ASSIGNED_P (conflict_a) - || ALLOCNO_HARD_REGNO (conflict_a) < 0) - && !(hard_reg_set_intersect_p - (profitable_hard_regs, - ALLOCNO_COLOR_DATA - (conflict_a)->profitable_hard_regs))))) - continue; + && ((!ALLOCNO_ASSIGNED_P (conflict_a) + || ALLOCNO_HARD_REGNO (conflict_a) < 0) + && !(hard_reg_set_intersect_p + (profitable_hard_regs, + ALLOCNO_COLOR_DATA + (conflict_a)->profitable_hard_regs)))) + { + /* All conflict allocnos are in consideration bitmap + when retry_p is false. It might change in future and + if it happens the assert will be broken. It means + the code should be modified for the new + assumptions. */ + ira_assert (bitmap_bit_p (consideration_allocno_bitmap, + ALLOCNO_NUM (conflict_a))); + continue; + } conflict_aclass = ALLOCNO_CLASS (conflict_a); ira_assert (ira_reg_classes_intersect_p [aclass][conflict_aclass]);