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 784543858D3C for ; Wed, 1 Feb 2023 12:40:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 784543858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 4F2F733D2C; Wed, 1 Feb 2023 12:40:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1675255258; 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=YeB7++qiKLUL8CEftON6fTyFddXsh2wxoapWf3VlhRo=; b=t5QExS9zUfldee4hjA+s3Utb2ctEkxnnlErmiKrwZr6pHi5Rxpe/7FGtEQNVeZ0S2Q12PJ GU53a4LonAMZtQSq9A1a+lB+joNTxViiXdJxNG3WltdbqBfZZjCqx0bgs5vuUpmlDMN3ac wuWF8z6E2nOcsNkZIqUwaz5RHHVlJ5w= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1675255258; 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=YeB7++qiKLUL8CEftON6fTyFddXsh2wxoapWf3VlhRo=; b=Txt5UKx4fbS70Qm4YcX/XTGJU2l5seW2MHtw/GpOYhXthdDq8kTG1ZME6VUDyaWMjGLWyv 2oX9bW+V/OmdXoBw== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 197B22C141; Wed, 1 Feb 2023 12:40:57 +0000 (UTC) Date: Wed, 1 Feb 2023 12:40:57 +0000 (UTC) From: Richard Biener To: Ju-Zhe Zhong cc: gcc-patches@gcc.gnu.org, kito.cheng@gmail.com, richard.sandiford@arm.com, jeffreyalaw@gmail.com, apinski@marvell.com Subject: Re: [PATCH] CPROP: Allow cprop optimization when the function has a single block In-Reply-To: <20230201122444.253620-1-juzhe.zhong@rivai.ai> Message-ID: References: <20230201122444.253620-1-juzhe.zhong@rivai.ai> User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-11.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, 1 Feb 2023, juzhe.zhong@rivai.ai wrote: > From: Ju-Zhe Zhong > > Hi, this patch is present for GCC 14 since I understand it's not appropriate > to land it in GCC 13. > > NUM_FIXED_BLOCKS = 2 since GCC define each function has aleast 2 blocks > one is entry block, the other is exit block. > So according this code, the function will not do cprop optimization when > there is only exactly one single block. cprop / GCSE are global dataflow problems, there's "nothing" to do for a single block, the local problem plus its application isn't considered but probably left for CSE. Why does CSE not perform the desired transform? > I am not sure whether it's correct to fix it like this. > Can anyone tell me why forbid cprop optimization if the function only has s > single block ? > > Let's take a look at these 2 examples of RVV intrinsics: > 1. void f1 (void * in, void *out, int64_t x, int n) > { > vint64m1_t v = __riscv_vle64_v_i64m1 (in + 1, 4); > vint64m1_t v2 = __riscv_vle64_v_i64m1_tu (v, in + 2, 4); > vint64m1_t v3 = __riscv_vadd_vx_i64m1 (v2, x, 4); > vint64m1_t v4 = __riscv_vadd_vx_i64m1 (v3, x, 4); > __riscv_vse64_v_i64m1 (out + 2, v4, 4); > } > > asm: > addi sp,sp,-16 > sw a2,8(sp) > sw a3,12(sp) > sw a2,0(sp) > sw a3,4(sp) > addi a5,a0,1 > vsetivli zero,4,e64,m1,ta,ma > addi a0,a0,2 > vle64.v v24,0(a5) > addi a5,sp,8 > vlse64.v v27,0(a5),zero > addi a1,a1,2 > vsetvli zero,zero,e64,m1,tu,ma > vle64.v v24,0(a0) > vsetvli zero,zero,e64,m1,ta,ma > vlse64.v v25,0(sp),zero > vadd.vv v26,v24,v27 > vadd.vv v24,v26,v25 > vse64.v v24,0(a1) > addi sp,sp,16 > jr ra > you can see here there are 2 vlse64.v instructions that broadcast the scalar value "x" > GCC fail to eliminate the second vlse64.v instruction since GCC doesn't do the cprop > optimization (the function only has 1 single block). It can be optimized if we apply > this patch. > > 2. void f1 (void * in, void *out, int64_t x, int n) > { > if (n) { > vint64m1_t v = __riscv_vle64_v_i64m1 (in + 1, 4); > vint64m1_t v2 = __riscv_vle64_v_i64m1_tu (v, in + 2, 4); > vint64m1_t v3 = __riscv_vadd_vx_i64m1 (v2, x, 4); > vint64m1_t v4 = __riscv_vadd_vx_i64m1 (v3, x, 4); > __riscv_vse64_v_i64m1 (out + 2, v4, 4); > } > } > > asm: > f1: > vsetivli zero,4,e64,m1,ta,ma > beq a4,zero,.L7 > addi sp,sp,-16 > sw a2,8(sp) > sw a3,12(sp) > addi a5,a0,1 > vle64.v v24,0(a5) > addi a0,a0,2 > addi a5,sp,8 > vlse64.v v25,0(a5),zero > addi a1,a1,2 > vsetvli zero,zero,e64,m1,tu,ma > vle64.v v24,0(a0) > vadd.vv v26,v24,v25 > vadd.vv v24,v26,v25 > vse64.v v24,0(a1) > addi sp,sp,16 > jr ra > .L7: > ret > > Here, if we add if (n) condition here, the program will end up with more than 1 block. > So GCC will do the cprop optimization and the second vlse64.v instruction is eliminated. > > I am not sure whether this patch is correct. > Can anyone help me with that ? > Thanks. > > > gcc/ChangeLog: > > * cprop.cc (one_cprop_pass): Remove +1. > > --- > gcc/cprop.cc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gcc/cprop.cc b/gcc/cprop.cc > index 6ec0bda4a24..615bc5078b6 100644 > --- a/gcc/cprop.cc > +++ b/gcc/cprop.cc > @@ -1749,7 +1749,7 @@ one_cprop_pass (void) > int changed = 0; > > /* Return if there's nothing to do, or it is too expensive. */ > - if (n_basic_blocks_for_fn (cfun) <= NUM_FIXED_BLOCKS + 1 > + if (n_basic_blocks_for_fn (cfun) <= NUM_FIXED_BLOCKS > || gcse_or_cprop_is_too_expensive (_ ("const/copy propagation disabled"))) > return 0; > > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)