From patchwork Wed Mar 12 15:37:17 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 329503 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 ACCDB2C00C2 for ; Thu, 13 Mar 2014 02:37:38 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; q=dns; s=default; b=MWDwGYRRvYfNBxFGEqdwpQFIJ/e5g 0QmXGRelZwnwS+OozQPy70wzRJDk+n9moozqmdkuzcLWyeTBkEkkyeR5jQ11oWBj EiU/EXcuXnl4LtvdtWUn1xyR5RGQEnpxh04WuxlscJy4EOoNC628t4CWXAuEJNrO jrxB7KD13XjVo0= 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:date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; s=default; bh=7YSyDwpVxIXIlwAvuVfeUUHhr8c=; b=mAh Fgj1TjQZ/Xzud8gBJPOTEMQDfjn1BKWV+zLrI3NvGI69Pzdd0Mk+0U+mVDHSkr1z Zc+VU5kh4PHYoo5G5NP0lL+yoO5IhBwVETf6cyQakU/JyQRNfE1RR3KIJaDfhiBt BtllE7xCBsntc48PeYreLiAP/ddaUG3UBHd+upig= Received: (qmail 20558 invoked by alias); 12 Mar 2014 15:37:30 -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 20540 invoked by uid 89); 12 Mar 2014 15:37:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL, BAYES_00, SPF_HELO_PASS, SPF_PASS, T_RP_MATCHES_RCVD 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 ESMTP; Wed, 12 Mar 2014 15:37:27 +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 s2CFbOhF025577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Mar 2014 11:37:25 -0400 Received: from tucnak.zalov.cz (ovpn-116-35.ams2.redhat.com [10.36.116.35]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2CFbMOP025822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Mar 2014 11:37:23 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.7/8.14.7) with ESMTP id s2CFbJjN021282; Wed, 12 Mar 2014 16:37:20 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.7/8.14.7/Submit) id s2CFbHCr021281; Wed, 12 Mar 2014 16:37:17 +0100 Date: Wed, 12 Mar 2014 16:37:17 +0100 From: Jakub Jelinek To: Richard Biener , "H.J. Lu" , Peter Bergner Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Try to avoid sorting on SSA_NAME_VERSION during reassoc (PR middle-end/60418) Message-ID: <20140312153716.GN22862@tucnak.redhat.com> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Hi! Apparently 435.gromacs benchmark is very sensitive (of course with -ffast-math) to reassociation ordering. We were sorting on SSA_NAME_VERSIONs, which has the disadvantage that we reuse SSA_NAME_VERSIONs from SSA_NAMEs dropped by earlier optimization passes and thus even minor changes in unrelated parts of function in unrelated optimizations can have very big effects on reassociation decisions. As discussed on IRC and in bugzilla, this patch attempts to sort on the ordering of SSA_NAME_DEF_STMT statements. If they are in different basic blocks, it uses bb_rank for sorting, if they are within the same bb, it checks which stmt dominates the other one in the bb (using gimple_uid). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2014-03-12 Jakub Jelinek PR tree-optimization/59025 PR middle-end/60418 * tree-ssa-reassoc.c (sort_by_operand_rank): For SSA_NAMEs with the same rank, sort by bb_rank and gimple_uid of SSA_NAME_DEF_STMT first. Jakub --- gcc/tree-ssa-reassoc.c.jj 2014-03-10 18:12:30.782215912 +0100 +++ gcc/tree-ssa-reassoc.c 2014-03-12 10:09:03.341757696 +0100 @@ -219,6 +219,7 @@ static struct pointer_map_t *operand_ran /* Forward decls. */ static long get_rank (tree); +static bool reassoc_stmt_dominates_stmt_p (gimple, gimple); /* Bias amount for loop-carried phis. We want this to be larger than @@ -506,11 +507,37 @@ sort_by_operand_rank (const void *pa, co } /* Lastly, make sure the versions that are the same go next to each - other. We use SSA_NAME_VERSION because it's stable. */ + other. */ if ((oeb->rank - oea->rank == 0) && TREE_CODE (oea->op) == SSA_NAME && TREE_CODE (oeb->op) == SSA_NAME) { + /* As SSA_NAME_VERSION is assigned pretty randomly, because we reuse + versions of removed SSA_NAMEs, so if possible, prefer to sort + based on basic block and gimple_uid of the SSA_NAME_DEF_STMT. + See PR60418. */ + if (!SSA_NAME_IS_DEFAULT_DEF (oea->op) + && !SSA_NAME_IS_DEFAULT_DEF (oeb->op) + && SSA_NAME_VERSION (oeb->op) != SSA_NAME_VERSION (oea->op)) + { + gimple stmta = SSA_NAME_DEF_STMT (oea->op); + gimple stmtb = SSA_NAME_DEF_STMT (oeb->op); + basic_block bba = gimple_bb (stmta); + basic_block bbb = gimple_bb (stmtb); + if (bbb != bba) + { + if (bb_rank[bbb->index] != bb_rank[bba->index]) + return bb_rank[bbb->index] - bb_rank[bba->index]; + } + else + { + bool da = reassoc_stmt_dominates_stmt_p (stmta, stmtb); + bool db = reassoc_stmt_dominates_stmt_p (stmtb, stmta); + if (da != db) + return da ? 1 : -1; + } + } + if (SSA_NAME_VERSION (oeb->op) != SSA_NAME_VERSION (oea->op)) return SSA_NAME_VERSION (oeb->op) - SSA_NAME_VERSION (oea->op); else