From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id DD6B73858D20 for ; Thu, 31 Aug 2023 11:26:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DD6B73858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=suse.cz Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 1355E2185A; Thu, 31 Aug 2023 11:26:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1693481198; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/JLU0cqcOTYbLtwK9wTLkyl3wL0ijQNa6ggRo8C4RPo=; b=BTtce8LUlzSU/uPggl8QR7gjfAZ7qLHBau7NS3PE2jxIn3lJOeYp1jCl8IkyhjieOhppfB jnt3ZTZKBW+6B3XPhrMRytP/6A5HE/KsXogAc6tUe5KDu63aPuN7fLrs+YKlZvx2wkgGg1 RwS6dmO5aYbpJeJpmW7iLnWKrmyEDA0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1693481198; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/JLU0cqcOTYbLtwK9wTLkyl3wL0ijQNa6ggRo8C4RPo=; b=vu9IiDFXftsxyhWwnngcKVHta14oyHcDyuCcBI4PDsckQhYEJ0T0VZLgc+q+28Gg3nYQAF jtw+8RlMdvHA1pCw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 07F4E13583; Thu, 31 Aug 2023 11:26:38 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id +afjAe548GQyWgAAMHmgww (envelope-from ); Thu, 31 Aug 2023 11:26:38 +0000 Date: Thu, 31 Aug 2023 13:26:37 +0200 From: Filip Kastl To: gcc-patches@gcc.gnu.org Cc: hubicka@ucw.cz, rguenther@suse.de, jakub@redhat.com Subject: Re: [RFC] gimple ssa: SCCP - A new PHI optimization pass Message-ID: References: <084BC52B-00DE-4496-8B85-9211C3AD8394@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_SOFTFAIL,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > The most obvious places would be right after SSA construction and before RTL expansion. > Can you provide measurements for those positions? The algorithm should only remove PHIs that break SSA form minimality. Since GCC's SSA construction already produces minimal SSA form, the algorithm isn't expected to remove any PHIs if run right after the construction. I even measured it and indeed -- no PHIs got removed (except for 502.gcc_r, where the algorithm managed to remove exactly 1 PHI, which is weird). I tried putting the pass before pass_expand. There isn't a lot of PHIs to remove at that point, but there still are some. 500.perlbench_r Started with 43111 Ended with 42942 Removed PHI % .39201131961680313700 502.gcc_r Started with 141392 Ended with 140455 Removed PHI % .66269661649881181400 505.mcf_r Started with 482 Ended with 478 Removed PHI % .82987551867219917100 523.xalancbmk_r Started with 136040 Ended with 135629 Removed PHI % .30211702440458688700 531.deepsjeng_r Started with 2150 Ended with 2148 Removed PHI % .09302325581395348900 541.leela_r Started with 4664 Ended with 4650 Removed PHI % .30017152658662092700 557.xz_r Started with 43 Ended with 43 Removed PHI % 0 > Can the pass somehow be used as part of propagations like during value numbering? I don't think that the pass could be used as a part of different optimizations since it works on the whole CFG (except for copy propagation as I noted in the RFC). I'm adding Honza into Cc. He'll have more insight into this. > Could the new file be called gimple-ssa-sccp.cc or something similar? Certainly. Though I'm not sure, but wouldn't tree-ssa-sccp.cc be more appropriate? I'm thinking about naming the pass 'scc-copy' and the file 'tree-ssa-scc-copy.cc'. > Removing some PHIs is nice, but it would be also interesting to know what > are the effects on generated code size and/or performance. > And also if it has any effects on debug information coverage. Regarding performance: I ran some benchmarks on a Zen3 machine with -O3 with and without the new pass. *I got ~2% speedup for 505.mcf_r and 541.leela_r. Here are the full results. What do you think? Should I run more benchmarks? Or benchmark multiple times? Or run the benchmarks on different machines?* 500.perlbench_r Without SCCP: 244.151807s With SCCP: 242.448438s -0.7025695913124297% 502.gcc_r Without SCCP: 211.029606s With SCCP: 211.614523s +0.27640683243653763% 505.mcf_r Without SCCP: 298.782621s With SCCP: 291.671468s -2.438069465197046% 523.xalancbmk_r Without SCCP: 189.940639s With SCCP: 189.876261s -0.03390523894928332% 531.deepsjeng_r Without SCCP: 250.63648s With SCCP: 250.988624s +0.1403027732444051% 541.leela_r Without SCCP: 346.066278s With SCCP: 339.692987s -1.8761915152519792% Regarding size: The pass doesn't seem to significantly reduce or increase the size of the result binary. The differences were at most ~0.1%. Regarding debug info coverage: I didn't notice any additional guality testcases failing after I applied the patch. *Is there any other way how I should check debug info coverage?* Filip K