From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95824 invoked by alias); 4 Dec 2015 12:45:36 -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 95810 invoked by uid 89); 4 Dec 2015 12:45:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: e06smtp13.uk.ibm.com Received: from e06smtp13.uk.ibm.com (HELO e06smtp13.uk.ibm.com) (195.75.94.109) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 04 Dec 2015 12:45:34 +0000 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 4 Dec 2015 12:45:31 -0000 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 4 Dec 2015 12:45:30 -0000 X-IBM-Helo: d06dlp03.portsmouth.uk.ibm.com X-IBM-MailFrom: vogt@linux.vnet.ibm.com X-IBM-RcptTo: gcc-patches@gcc.gnu.org Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 948081B08067 for ; Fri, 4 Dec 2015 12:45:56 +0000 (GMT) Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id tB4CjT3r48693426 for ; Fri, 4 Dec 2015 12:45:29 GMT Received: from d06av03.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id tB4CjThs016146 for ; Fri, 4 Dec 2015 05:45:29 -0700 Received: from bl3ahm9f.de.ibm.com (sig-9-84-10-89.evts.de.ibm.com [9.84.10.89]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id tB4CjS9c016074; Fri, 4 Dec 2015 05:45:29 -0700 Received: from dvogt by bl3ahm9f.de.ibm.com with local (Exim 4.76) (envelope-from ) id 1a4pjo-0008MQ-Ai; Fri, 04 Dec 2015 13:45:24 +0100 Date: Fri, 04 Dec 2015 12:45:00 -0000 From: Dominik Vogt To: gcc-patches@gcc.gnu.org Cc: Alexandre Oliva , Andreas Krebbel Subject: Re: [PR64164] drop copyrename, integrate into expand Message-ID: <20151204124523.GA31784@linux.vnet.ibm.com> Reply-To: vogt@linux.vnet.ibm.com Mail-Followup-To: gcc-patches@gcc.gnu.org, Alexandre Oliva , Andreas Krebbel References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15120412-0013-0000-0000-000007E2D05A X-SW-Source: 2015-12/txt/msg00552.txt.bz2 On Fri, Mar 27, 2015 at 03:04:05PM -0300, Alexandre Oliva wrote: > This patch reworks the out-of-ssa expander to enable coalescing of SSA > partitions that don't share the same base name. This is done only when > optimizing. > > The test we use to tell whether two partitions can be merged no longer > demands them to have the same base variable when optimizing, so they > become eligible for coalescing, as they would after copyrename. We then > compute the partitioning we'd get if all coalescible partitions were > coalesced, using this partition assignment to assign base vars numbers. > These base var numbers are then used to identify conflicts, which used > to be based on shared base vars or base types. > > We now propagate base var names during coalescing proper, only towards > the leader variable. I'm no longer sure this is still needed, but > something about handling variables and results led me this way and I > didn't revisit it. I might rework that with a later patch, or a later > revision of this patch; it would require other means to identify > partitions holding result_decls during merging, or allow that and deal > with param and result decls in a different way during expand proper. > > I had to fix two lingering bugs in order for the whole thing to work: we > perform conflict detection after abnormal coalescing, but we computed > live ranges involving only the partition leaders, so conflicts with > other names already coalesced wouldn't be detected. The other problem > was that we didn't track default defs for parms as live at entry, so > they might end up coalesced. I guess none of these problems would have > been exercised in practice, because we wouldn't even consider merging > ssa names associated with different variables. > > In the end, I verified that this fixed the codegen regression in the > PR64164 testcase, that failed to merge two partitions that could in > theory be merged, but that wasn't even considered due to differences in > the SSA var names. > > I'd agree that disregarding the var names and dropping 4 passes is too > much of a change to fix this one problem, but... it's something we > should have long tackled, and it gets this and other jobs done, so... > > Regstrapped on x86_64-linux-gnu native and on i686-pc-linux-gnu native > on x86_64, so without lto. Is this ok to install? The patch that got committed as a result of this discussion causes a performance regression on s390[x]. Bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695 Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany